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SUMMARY 


BACKGROUND 

Operational  support  costs  represent  a  large  percentage  of  the  total 
life  cycle  cost  of  major  weapon  systems.  The  cost  of  human  resources 
(manpower,  personnel,  training,  etc.),  is,  in  turn,  one  of  the  largest 
contributors  to  operational  support  costs.  To  a  significant  degree, 
operational  support  costs  are  determined  by  the  operational/support 
concepts  and  performance/design  characteristics  of  the  weapon  system 
hardware.  Finally,  most  of  the  system  concept  and  design  decisions 
that  significantly  influence  operational  support  costs  are  made  during 
the  early  (conceptual  and  validation)  program  phases. 

Department  of  Defense  (DOD)  policy  has  increasingly  emphasized  the 
need  for  developing  ways  to  reduce  operational  support  costs  while 
maintaining  mission  effectiveness  of  weapon  systems.  For  the  past  10 
years,  the  Logistics  and  Technical  Training  Division  of  the  Air  Force 
Human  Resources  Laboratory  (AFHRL)  has  been  developing  basic  technology 
addressing  the  relationships  between  human  resources  and  complex  weapon 
systems.  This  technology  attempts  to  make  it  possible  for  manpower, 
personnel  and  training  factors  to  have  an  influence  on  the  hardware 
design/development  process  as  well  as  to  be  influenced  by  it. 

For  many  years,  a  large  volume  of  historical  data  (human  resource 
related)  on  operational  weapon  systems  has  been  collected  and  processed. 
Historically,  the  primary  use  of  these  data  has  been  to  improve  the 
operation  and  support  (O&S)  capabilities  of  existing  systems,  and  the 
data  systems  have  been  tailored  to  satisfy  these  objectives. 

In  recent  years,  it  has  become  evident  that  a  unified  data  base 
(UDB)  of  human  resources  information  is  needed  to  support  the  weapon 
system  acquisition  process.  The  primary  objective  of  this  study  was  to 
establish  an  initial  plan  for  development  of  a  centrally  located  com¬ 
puterized  on-line  UDB  of  human  resource  related  information  for  utili¬ 
zation  in  the  weapon  system  acquisition  process  to  influence  hardware 
concepts  and  design. 

The  study  consisted  of  four  major  tasks.  The  first  was  to  iden¬ 
tify  data  and  data  systems  that  would  be  useful  in  the  weapon  system 
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design  process.  The  second  was  to  define  the  system  design  process  and 
to  determine  the  extent  to  which  human  resources  data  (HRD)  are  used  in 
early  system  design.  The  third  was  to  assess  the  availability  and  ade¬ 
quacy  of  existing  HRD  for  use  in  system  design,  and  to  identify  re¬ 
quirements  for  improving  those  data.  The  fourth  (which  this  report 
addresses)  was  to  establish  an  initial  plan  for  future  development  of  a 
prototype  UDB. 

PROBLEM 

There  is  a  need  for  a  UDB  that  will  more  effectively  utilize  his¬ 
torical  data  and  provide  a  systematic,  consistent  way  to  develop  and 
record  HRD  for  an  evolving  new  weapon  system.  There  is  also  a  need  for 
a  data  generating  technology  base  (DCTB)  of  technologies  that  provide 
generic  and  parametric  HRD  that  will  support  weapon  system  designers  in 
a  timely  manner  such  that  a  significant  reduction  in  O&S  costs  can  be 
made  by  early  trade-off  analyses  which  address  human  resources  and 
logistics  factors.  HRD  is  fundamentally  those  data  that  would  assist 
in  obtaining  answers  to  questions  about  O&S  requirements  us  a  function 
of  alternative  design  concepts  and/or  approaches  for  system  hardware 
and  alternative  support  concepts.  In  this  context,  HRD  includes  infor¬ 
mation  about  manpower,  skills,  skill  levels,  reliability  (R) ,  maintain¬ 
ability  (M) ,  support  equipment,  spares,  training,  and  technical  manuals. 

APPROACH 

The  approach  taken  involved  four  steps.  First,  the  results  of  the 
previous  three  tasks  of  this  overall  study  were  synthesized  and  ana¬ 
lyzed  since  the  proposed  development  for  the  UDB  is  to  be  based  on  the 
results  of  these  previous  efforts.  In  general,  these  results  addressed 
(a)  the  existing  Air  Force,  Army,  Navy,  and  other  data  bases  which 
could  feasibly  "feed"  the  UDB,  (b)  the  weapon  system  design  and  acqui¬ 
sition  process,  in  order  to  later  establish  the  requirements,  potential 
use,  and  operational  concepts  for  the  proposed  UDB,  and  (c)  user  needs, 
in  terms  of  the  adequacy  of  the  data  systems  i nvest igated. 

Second,  the  concept  of  a  UDB  and  a  supporting  DCTB  was  developed. 


The  DGTB  is  intended  to  generate  generic  data  to  fill  in  the  needs  of 
users  where  the  data  systems,  and  likewise  the  UDB,  would  leave  voids. 
The  DGTB  would  include  various  technologies  that  use  standard  analyti¬ 
cal  techniques  (e.g.,  parametric  estimating  relationships,  regression 
analysis,  comparability  analysis,  expected  value  techniques)  to  provide 
initial  data  values  in  the  very  early  stages  of  weapon  system  design 
until  more  reliable  values  emerge  as  a  result  of  the  system  design  and/ 
or  test  process.  This  concept  was  found  to  be  necessary  during  the 
first  three  tasks  of  the  total  study. 

Third,  a  concept  of  operational  use  for  the  UDB/DGTB  was  defined. 
This,  too,  was  based  on  the  results  of  the  first  three  tasks. 

Finally,  the  technical  approach  for  the  development  of  a  prototype 
UDB/DGTB  was  established.  It  was  based  on  (a)  the  results  of  the  first 
three  tasks,  (b)  an  investigation  of  the  development  process  of  other 
previous  analogous  but  less- encompassing  technologies  (e.g.,  the  Army 
Logistics  Support  Analysis/Logistics  Support  Analysis  Record  (LSA/LSAR), 
Boeing  Aircraft  Company's  LSAR),  (c)  a  prioritization  of  the  data  sys¬ 
tems  and  data  generating  technologies  investigated,  and  (d)  an  analysis 
of  an  industry  survey  which  addressed  the  structure  of  a  UDB/DGTB. 

CONCLUSIONS 

The  following  results  are  documented  in  this  report: 

1.  A  review  of  the  first  task  (the  data  system  review)  indicated 
that  the  data  are  available,  formatted,  and  standardized,  thus  making  a 
UDB  feasible  from  this  standpoint. 

2.  A  review  of  the  second  task  (the  weapon  system  design  process) 
indicated  that  a  realistic  concept  of  operation  for  a  UDB  is  feasible. 

3.  A  review  of  the  third  task  (identification  of  user  needs)  in¬ 
dicated  that  a  UDB  is  needed  and  would  be  used. 

4.  A  more  detailed  concept  for  a  UDB  and  DGTB  is  developed. 

The  UDB  would  contain  two  different  types  of  information.  The 

first  type  would  be  information  about  an  existing  aircraft  weapons  sys¬ 
tem  that  most  closely  compares  with  the  new  aircraft  systan  under 
development.  The  second  type  would  be  information  about  the  new  air¬ 
craft  system  under  development.  The  latter  would  expand  in  time  with 


the  ever-increasing  definition  and  design  of  the  new  system.  The  data 
format  in  the  UDB  should  be  compatible  not  only  with  the  weapon  systan 
design  and  acquisition  process  but  also  with  the  testing,  operational 
and  support  processes. 

The  DGTB  should  provide  many  initial  values  for  the  UDB  elanents. 
These  initial  values  would  be  eventually  supplanted  by  better  values 
based  upon  more  detailed  design,  hardware,  and/or  test  information.  It 
is  quite  conceivable  that  data  in  the  UDB,  associated  with  a  comparable 
but  earlier  generation  weapon  system,  would  be  used  as  input  to  the 
DGTB  to  obtain  "next  generation"  initial  values. 

This  concept  is  patterned  somewhat  after  the  Army's  LSA/LSAR  tech¬ 
nology  in  that  the  format  and  standardization  techniques  are  adapted, 
but  are  modified  in  accordance  with  guidance  from  an  on-going  tri¬ 
services  LSAR  working  group.  The  idea  of  basing  the  UDB  technology 
upon  the  LSAR  was  supported  by  the  industry  survey  results.  The  re¬ 
sulting  UDB  concept  is  also  patterned  after  the  Logistics  Composite 
Model  (LCOM)  and  Common  Data  Extraction  Program  (CDEP)  technology  in 
that  a  central  repository  of  data  is  maintained,  updated,  and  kept 
traceable.  It  is  maintained  either  on  computer  disc  or  in  magnetic 
tape  libraries.  The  success  associated  with  an  Air  Force  Avionics  Lab¬ 
oratory  technology  called  system  avionics  valve  estimation  (SAVE)  also 
impacted  the  resulting  concept  for  a  UDB/DGTB.  The  DGTB  concept  itself 
was  introduced  successfully  by  SAVE. 

5.  A  more  detailed  concept  of  operational  use  for  the  UDB/DGTB 
is  defined.  This  concept  is  based  primarily  on  the  results  of  studying 
the  weapon  system  design  process  and  a  more  in-depth  look  at  the  indus¬ 
try  survey.  The  UDB/DGTB  would  be  used  in  the  very  earliest  phase  of 
weapon  system  design  (conceptual  phase)  and  would  continue  to  be  used 
throughout  the  acquisition  process.  Historical  baseline  data  in  the 
UDB  would  be  used  for  comparability  analyses  at  the  outset  of  a  new 
acquisition  program.  Similarly,  the  DGTB  would  be  of  more  importance 
during  the  Conceptual  Phase,  since  it  would  provide  predictive  data 
related  to  human  resources  and  logistics  support  (HR&LS)  factors.  The 
UDB  would  provide  space  for  recording  the  required,  predicted,  and 
denonstrated  values  for  each  important  parameter  of  HRD  related  to  the 


new  weapon  system.  Although  these  data  would  continually  be  updated,  a 
permanent  record  would  be  provided  (possibly  on  magnetic  tape)  at  each 
major  milestone  of  the  Defense  Systems  Acquisition  Review  Council 
(DSARC) .  The  users  of  the  UDB/DGTB  would  be  those  government  agencies 
primarily  involved  in  the  weapon  systen  acquisition  process,  including 
their  industry  counterparts.  The  housekeepers  of  the  UDB/DGTB  would  be 
the  Air  Force  Acquisition  Logistics  Division  (AFALD)  of  the  Air  Froce 
Logistics  Command  (AFLC) . 

6.  Finally,  the  technical  approach  for  the  development  of  a  pro¬ 
totype  UDB/DGTB  is  established.  This  result  represents  the  climax  of 
the  total  study,  as  well  as  an  integration  of  all  previous  results  into 
a  proposed  plan  of  action. 

The  UDB/DGTB  technology  is  evolving  in  the  heuristic  manner.  At 
this  stage  of  the  development  process,  the  initial  outline  for  a  UDB/ 
DGTB  can  be  identified.  This  outline  is  based  on  a  prioritization  of 
the  more  important  data  systems  and  technologies  which  the  UDB/DGTB 
should  accommodate.  The  more  important  data-producing  systems  for  the 
UDB  are  listed  by  order  of  importance:  LSAR,  LCOM/CDEP,  Air  Force 
Guide-2,  and  an  Air  Force  Test  and  Evaluation  Center  technology  called 
OMNIVORE.  The  use  of  these  four  systems  will  require  use  of  many  other 
data  systems  discussed  in  AFHRL- TR-79-36  since  these  in  turn  "feed"  the 
preceding  four. 

The  more  important  technologies  for  the  DGTB  are  ranked  and  in¬ 
clude  parametric  estimating  relationships  (PER),  expected  value  tech¬ 
niques,  LSA,  comparability  analysis,  optimal  repair  level  analysis. 

The  UDB/DGTB  technology  development  effort  is  scoped  to  be  in 
three  phases:  (a)  finalize  the  UDB/DGTB  definition,  an  effort  which 
will  clearly  define  what  data  systems  and  what  data  generating  tech¬ 
nologies  will  be  addressed  in  the  prototype  UDB/DGTB,  (b)  develop  the 
software,  and  (c)  test  and  danonstrate  the  software  and  its  ability  to 
meet  the  requirements  of  the  UDB  concept.  Each  phase  will  last  about 
1  year,  and  each  phase  will  require  about  3  work-years  of  effort. 

The  recommended  process  for  the  development  of  a  prototype  UDB/ 
DGTB  technology  assumes  a  contractual  effort.  The  contractor  should 
submit  performance  plans  that  would  be  approved  by  a  special  Air  Force 


advisory  group  at  various  milestones  in  the  development  process.  This 
advisory  group  could  quite  feasibly  be  composed  of  those  individuals  on 
the  tri-services  LSAR  working  group,  plus  other  selected  individuals. 
The  final  UDB/DGTB  description  will  depend  on  the  "feedback"  from  this 
advisory  group. 
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SECTION  I 
INTRODUCTION 

GENERAL 

The  primary  objective  of  this  study  is  to  establish  an  initial 
plan  for  development  of  a  Unified  Data  Base  (UDB)  of  human  resource 
(HR)  related  information  for  utilization  in  the  weapons  system  acquisi¬ 
tion  process  to  influence  system  design.  The  output  of  this  study  will 
be  four  reports: 

Report  I:  Thomas  and  Hankins  (1980). 

Report  II:  Thomas,  Hankins,  and  Newhouse  (1979a). 

Report  III:  Thomas,  Hankins,  and  Newhouse  (1979b). 

This  report  (Report  IV)  presents  the  basic  plan  and  recommenda¬ 
tions  for  development  of  a  prototype  UDB  and  Data  Generating  Technology 
Base  (UDB/DGTB).  The  results  of  Reports  I,  II,  and  III  of  this  study 
were  used  to  develop  the  concept  of  the  UDB/DGTB,  the  development  ap¬ 
proach,  and  the  manner  in  which  it  should  be  used. 

As  used  in  this  study,  human  resources  data  (HRD)  refers  to  infor¬ 
mation  for  use  during  design/development  phases  that  provides  impact 
estimates  or  otherwise  describes  ground  support  human  resource  require¬ 
ments  (HRR)  in  the  operation  and  support  (O&S)  phase  of  a  weapon  system. 
HRD  are  fundamentally  those  data  which  would  assist  in  obtaining  answers 
to  the  following  questions  about  O&S  ground  support  requirements  as  a 
function  of  alternative  design  concepts/approaches  for  system  hardware 
and  alternative  support  concepts: 

How  many  people  are  needed? 

What  type  of  skills  and  skill  levels  are  needed? 

How  available  and  perishable  are  the  people  needed? 

How  much  will  the  people  cost? 

In  the  preceding  context,  HRD  relates  directly  or  indirectly  to  relia¬ 
bility  and  maintainability  (R&M),  personnel,  training,  technical  data, 
manpower  costs,  test  support  equipment,  and  human  engineering  informa¬ 
tion — regardless  of  the  source,  form,  and  content. 


The  fundamental  criteria  that  guided  the  study  efforts  leading  to 
this  report  were  as  follows: 

1.  The  UDB/DGTB  is  basically  a  system  to  support  the  design 
process  in  major  weapon  systems  acquisition. 

2.  Existing  historical  data  systems  will  be  utilized  to  the 
maximum  extent  practical. 

3.  Established  and  validated  data  generating  technology  will 
be  utilized  to  the  maximum  extent  practical. 

4.  Duplication  and  redundancy  of  data  and  data  systems  will  be 
avoided  and  reduced. 

5.  Consistency  and  compatibility  of  data  elements  will  be 
insured  so  as  to  provide  a  common  thread  of  HRD  from  the 
conceptual  phase  to  deployment  of  a  weapon  system. 

6.  Modifications  required  of  existing  data  systems  and  tech¬ 
nology  will  be  consistent  with  satisfying  user  needs  and 
the  other  criteria. 

While  "satisfying  validated  user  needs  at  minimum  cost"  is  not  stated 
as  a  specific  criterion,  a  UDB/DGTB  that  satisfies  the  criteria  listed 
will  significantly  reduce  the  overall  cost  of  data  collection,  reduc¬ 
tion,  processing,  analysis,  and  reporting  by  government  and  industry 
during  research,  development,  test,  and  evaluation  (RDT&E) .  More  im¬ 
portantly,  the  UDB/DGTB  should  ultimately  result  in  significant  reduc¬ 
tions  in  O&S  costs  for  weapon  systems  without  sacrificing  required 
operational  effectiveness. 


CONTENTS  OF  REPORT 

This  report  is  divided  into  four  major  sections.  Section  II  inte¬ 
grates  the  results  of  Reports  I,  II,  and  III  of  this  study  and  presents 
the  major  findings  and  conclusions.  Section  III  presents  the  concept 
of  a  UDB/DGTB.  Section  IV  presents  the  concept  of  operation  of  the 
UDB/DGTB  and  how  each  user  could  utilize  the  system.  Section  V  pre¬ 
sents  the  development  approach  for  the  prototype  UDB/DGTB. 
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CONSOLIDATION  OF  PREVIOUS  STUDY  REPORTS 

GENERAL 

In  order  to  establish  an  initial  plan  for  the  development  of  a 
UDB,  three  prerequisite  tasks  were  accomplished  and  documented  in 
Reports  I,  II  and  III  mentioned  in  Section  I.  Report  I  identifies  ex¬ 
isting  data  and  data  systems  that  relate  to  HRD  and  that  are  useful  in 
the  system  design  process.  Report  II  describes  the  weapon  system  de¬ 
sign  process  with  specific  emphasis  on  the  utilization  of  HRD  to  influ¬ 
ence  hardware  design.  An  industry  survey  was  used  to  provide  input 
data  for  this  effort.  Report  III  considers  the  adequacy  of  existing 
HRD  and  the  identification  of  new  and/or  modified  HRD  for  use  in  vari¬ 
ous  phases  of  system  design,  and  an  assessment  of  some  existing  data 
systems  and  selected  data  generating  technologies  (DGT)  which  were 
introduced  in  Report  I.  Again,  the  industry  survey  was  used  to  provide 
input  data  for  this  effort.  This  section  synthesizes  and  summarizes 
the  major  findings  and  the  results  of  Report  I,  II,  and  III. 

EXISTING  DATA/DATA  SYSTEMS 

Several  data/data  systems  being  utilized  by  the  Air  Force  are 
directly  related  to  HRD  and  could  be  useful  and  usable  in  the  system 
design  process.  These  include  the  base  level  maintenance  data  collec¬ 
tion  system  (MDCS) ,  base  level  maintenance  cost  system  (MDS:H-129), 
aerospace  vehicle  inventory  status  (GO  33),  weapons  system  effective¬ 
ness  programs  and  models  (KO  51),  USAF  cost  and  planning  factors  (AFR 
173-10),  Logistics  Support  Analysis  (LSA)  (MIL-STD- 1388-1) ,  unit  costs 
of  aircraft,  guided  missiles,  and  engines  (TO  00-25-30),  standard  air¬ 
craft  characteristics  (Air  Force  Guide-2),  group  weight  statements  (AN- 
9103-D)  and  systems  effectiveness  data  system  (SEDS) .  While  the  pri¬ 
mary  source  of  HRD  is  without  doubt  the  existing  MDCS  and  the  Air  Force 
Logistics  Command  (AFLC)  by-products  generated  from  this  source  data, 
the  other  data  sources  are  also  very  useful  as  they  apply  to  the  devel¬ 
opment  of  a  comprehensive  historical  data  base  for  future  weapon  systems 


programs.  This  is  particularly  true  of  the  LSA  and  resulting  logistics 
support  analysis  record  (LSAR)  system  after  it  has  been  applied  to 
specific  acquisition  programs. 

All  in  all,  there  is  an  enormous  volume  of  operation  source  data 
related  either  directly  or  indirectly  to  HRD.  Existing  operational 
data  systems  use  these  source  data  to  generate  many  by-products  for 
logistic  support  planning,  budgeting,  and  management  of  all  levels 
within  the  Air  Force  management  structure. 

HUMAN  RESOURCES  TECHNOLOGIES 

Much  research  has  been  or  is  being  conducted  to  develop  technolo¬ 
gies  that  will  enable  human  resource  and  logistics  support  (HR&LS) 
factors  to  Influence  weapon  system  design  and  development.  Specific 
technologies  identified  fall  into  the  areas  of  HR&LS  as  design  con¬ 
straints,  HR&LS  in  design  trade-offs,  computerized  HRD  for  system 
design,  HR&LS  requirements  prediction  (analytic  and  simulation  tech¬ 
niques),  HR&LS  design  handbooks,  and  life  cycle  costing  models. 

The  area  of  HR&LS  as  design  constraints  is  concerned  with  the 
feasibility  of  using  HR&LS  parameters  to  establish  "design  to'  require¬ 
ments  for  system  hardware.  Studies  by  Shapero  and  Bates  (1959);  Hannah, 
Boldov  lei,  Altman,  and  Manlon  (1965);  Hannah  and  Reed  (1965);  Snyder 
and  Askren  (1968);  Lintz  (1973);  Potter,  Korkan,  and  Dieterlv  (1975a); 
and  Askren  (1976)  developed  techniques  for  using  HR&LS  factors  an 
engineering  design  criteria.  Six  studies  by  Meister  and  Farr  (1966); 
Meister  and  Sullivan  (1967);  Meister,  Sullivan,  and  Askren  (1968); 
Meister,  Sullivan,  Finley,  and  Askren  (1969a,  1969b);  Meister,  Finley, 
and  Thompson  (1971)  resulted  in  valuable  knowledge  and  insights  about 
how  designers  perceive  HR&LS  factors,  and  how  HRD  are  and  can  be  used 
in  system  design.  Meister  concluded,  among  other  things,  that  (a)  HRD 
is  used  by  designers  but  the  influence  on  design  varies  considerably, 

(b)  the  more  detailed  the  HRD,  the  more  weight  it  receives  in  design 
decisions,  and  (c)  the  extent  to  which  HRD  influences  design  is  a 
function  of  its  quantity,  quality,  and  availability. 

Numerous  studies  have  investigated  the  feasibility  of  considering 
HR&LS  factors  in  design  trade-off  analyses.  Askren  and  Korkan  (1971); 


Askren,  Korkan,  and  Watts  (1973);  Askren  (1973)  developed  the  design 
option  decision  tree  (DODT)  approach  and  demonstrated  that  early  design 
trade-off  studies  frequently  impact  HR&LS  factors.  Lintz,  Askren,  and 
Lott  (1971);  Walen  and  Askren  (1974);  and  Potter,  Korkan,  and  Dieterly 
(1975b)  advanced  the  works  of  Askren  by  studying  applications  of  DODT 
to  other  areas  of  system  hardware. 

During  the  1960's,  studies  by  Reed,  Foley,  Graham,  and  Hilgeman 
(1963);  Whiteman  (1965);  Tulley  and  Meyer  (1967);  Potter,  Tulley,  Reed, 
and  Lawrence  (1968);  and  Reardon  (1968)  were  accomplished  to  computerize 
HRD  for  use  in  system  design.  This  effort  concentrated  on  the  genera¬ 
tion  and  flow  of  HRD  in  the  design  process  using  network  diagrams. 
Apparently  lacking  support,  the  emphasis  in  the  1970's  shifted  to  pre¬ 
diction  of  HRR  by  means  of  computer  simulations.  The  coordinated  works 
by  Drake  (1974);  Hicks  and  Tetmeyer  (1974);  Maher  and  York  (1974); 
Moody,  Tetmeyer,  and  Nichols  (1974);  Tetmeyer  (1974);  Tetmeyer  and 
Moody  (1974);  Tetmeyer,  Nichols,  Hart,  and  Maher  (1976);  and  Tetmeyer, 
Nichols,  and  Deem  (1976)  resulted  in  the  development  of  sophisticated 
and  effective  simulation  techniques  for  considering  and  predicting 
HR&LS  requirements.  Today,  simulation  techniques  are  increasingly  used 
to  predict  integrated  logistics  support  requirements  for  weapon  sys¬ 
tems.  The  Logistics  Composite  Model  (LCOM)  is  the  most  current  model 
and  is  frequently  used  in  the  Air  Force,  although  its  effective  use  in 
the  conceptual  phase  is  limited  by  the  lack  of  system  design  defini¬ 
tion. 

HR&LS  requiranents  prediction  via  analytical  techniques  has  been 
increasingly  applied  in  the  area  of  system  design.  Purvis,  McLaughlin, 
and  Mallory  (1964);  and  Purvis,  Mallory,  and  McLaughlin  (1965)  investi¬ 
gated  the  use  of  queueing  techniques  to  determine  manning  and  related 
support  requirements.  Mills,  Backert,  and  Hatfield  (1975)  investigated 
human  performance  in  terms  of  task  performance  reliability  and  time. 
Forecasting  techniques  developed  by  Widenhouse  and  Romano  (1977)  fo¬ 
cused  on  operational  reliability  and  maintenance  support.  The  most 
promising  developments  for  application  to  the  early  stages  of  weapon 
systan  design  have  been  in  the  area  of  cost  and  parametric  estimating 
relationships  (CER/PER) .  Work  by  Hankins  (1978)  is  representative  of 


the  advancements  that  have  been  achieved  in  developing  CER/PER  models 
that  can  be  used  during  the  conceptual  and  preliminary  design  stages  of 
acquisition  programs. 

In  the  area  of  HR&LS  design  handbooks,  Boeing  Company  (1975)  de¬ 
veloped  an  approach  for  specifying  training  and  training  equipment  re¬ 
quirements.  Reed,  Snyder,  Baran,  Loy,  and  Curtin  (1975)  developed  a 
prototype  design  handbook  that  addressed  a  wide  range  of  HR&LS  data, 
and  Meister  (1976)  found  that  it  would  be  most  helpful  to  expand  the 
availability  and  use  of  HR&LS  design  handbooks. 

The  Air  Force  Human  Resources  Laboratory  (AFHRL)  has  sponsored 
numerous  projects  to  develop  improved  technology  in  the  area  of  job 
guide  design.  Works  by  Foley  (1972,  1973)  and  Joyce  (1973a,  1973b, 
1973c)  are  representative  of  the  major  advances  that  have  been  made  to 
improve  maintenance  technical  orders  and  job  performance  aids. 

Many  life  cycle  cost  (LCC)  models  have  been  developed  to  predict 
and  control  acquisition  costs  and  costs  of  ownership.  Gibson  (1975), 
Menker  (1975)  and  Collins  (1976)  have  developed  a  library  of  LCC  models 
and  guides  for  using  them.  The  models  most  frequently  used  by  the  Air 
Force  in  weapon  system  acquisition  programs  are  the  cost  analysis/cost 
estimating  (CACE)  and  the  logistics  support  cost  (LSC)  models  (Thomas 
and  Hankins,  1980,  pp.  97-101).  Important  studies  by  Cerone  (1972); 
Cork  and  Mueahy  (1977);  and  Czuchy,  Clasier,  Kistler,  Bristol,  Baran, 
and  Dieterly  (1978)  have  produced  cost  of  ownership  models  that  could 
be  effectively  utilized  in  the  system  acquisition  process. 

The  recent  AFHRL  efforts  by  Goclowski  (1978a,  1978b,  1978c)  to 
develop  criteria  for  a  Consolidated  Data  Base  (CDB)  to  support  the 
coordinated  human  resources  technology  (CHRT)  are  directly  related  to 
the  AFHRL  efforts  by  Clanson  University  (Thomas  and  Hankins,  1980  and 
this  report).  It  is  believed  that  the  CDB  should  be,  to  the  maximum 
extent  possible,  an  integral  part  of  the  UDB  described  later  in  this 
report,  and  further,  that  the  CHRT  should  be  incorporat ed  into  the 
DGTB,  as  appropriate. 

Overall,  the  available  HR  technology,  and  its  associated  litera¬ 
ture,  is  extensive.  The  collective  work  of  AFHRL  is  clearly  represen¬ 
tative  of  the  current  state  of  the  art  in  this  area.  The  technologies 
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developed  by  AFHRL  demonstrate  that  HRD  can  be  used  to  influence  the 
design  of  complex  system  hardware.  When  viewed  in  the  light  of  a  total 
weapon  system  development  program,  however,  the  existing  data  base  to 
support  these  technologies  is  critically  underdeveloped. 

THE  WEAPON  SYSTEM  DESIGN  PROCESS 

Current  Department  of  Defense  (DOD)  documentation  was  reviewed  to 
provide  an  overview  of  the  weapon  system  design  process  during  the 
conceptual  and  validation  phases  of  an  aircraft  research,  development, 
test,  and  evaluation  (RDT&E)  program.  A  compr ehensive  industry  survey 
was  conducted  to  define  specific  activities,  documentation,  and  the  ex¬ 
tent  of  subsystem  design  accomplished  during  these  early  program  phases . 
In  addition,  the  survey  was  used  to  obtain  inputs  to  determine  the 
availability,  utilization,  adequacy,  and  source  of  HRD  used  in  the  de¬ 
sign  process. 

A  separate  questionnaire  was  prepared  for  three  types  of  engineers 
— chief /project  engineers  (PE),  design  engineers  (DE) ,  and  R&M/integra- 
ted  logistic  support  engineers  (ILS).  Of  15  companies  contacted,  9 
agreed  to  participate  in  the  study.  Table  1  shows  the  number  of  re¬ 
spondents  according  to  the  companies'  primary  product  type  and  type 
engineer. 

TABLE  1.  SURVEY  RESPONDENTS 


Type  Produce 

PE 

DE 

ILS 

Total 

Fighter 

11 

39 

10 

60 

Bomber 

7 

28 

8 

43 

Transport 

4 

16 

10 

30 

Avionics 

6 

17 

5 

28 

Total 

28 

100 

33 

161 

survey  results 

show  that. 

during 

the 

conceptual  pi 

tional  and  support  scenarios/plans  are  established,  weapon  system  per¬ 
formance  specifications  are  defined,  arid  top-level  systan  and  subsystem 
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design  is  completed.  Early  validation  phase  activity  includes  pre¬ 
liminary  design  of  the  airframe,  propulsion  and  other  subsystems 
affecting  overall  system  performance.  This  activity  includes  interface 
definition,  integration  top-level  drawings  and  schematic  diagrams.  By 
the  end  of  the  validation  phase,  the  performance  specifications  for  all 
subsystems  are  established  and  documented.  When  prototype  demonstra¬ 
tions  are  involved,  detailed  design,  fabrication,  and  testing  of 
mission-critical  subsystems  are  accomplished  in  the  validation  phase. 

Regardless  of  the  management  approach  used,  the  majority  of  all 
major  design  decisions  will  have  been  made  by  the  end  of  the  validation 
phase.  The  conceptual  design  phase  (CDP)  coincides  with  the  conceptual 
phase  of  a  program,  while  the  preliminary  design  phase  (PDP)  generally 
coincides  with  the  validation  phase  of  a  program.  Strictly  speaking, 
the  conceptual  phase  includes  all  CDP  and  some  initial  PDP  activity, 
while  the  validation  phase  includes  the  remaining  PDP  and  some  initial 
detailed  design  phase  (DDP)  activity.  Throughout  the  CDP  and  PDP,  de¬ 
sign  trade  studies  represent  the  best  mechanism  whereby  human  resources 
factors  (HRF)  may  be  considered  to  influence  system  hardware  design 
decisions . 

The  major  engineering  activities  and  documentation  completed  in 
the  CDP  include  relatively  little  emphasis  on  HRR.  When  attention  is 
given  to  HRR,  it  generally  occurs  in  trade  studies.  It  should  be  noted 
that  in  this  report,  trade  studies  refer  to  conceptual  trade-off,  para¬ 
metric  trade-off,  or  design  trade-off  studies.  During  the  PDP,  in¬ 
creased  emphasis  on  HRR  occurs  but  it  is  still  a  relatively  small 
amount.  The  primary  mechanisms  to  consider  HRR  are  R&M  engineering  and 
trade  studies.  The  analysis  revealed  that  LSA  is  not  usually  initiated 
until  after  PDP  has  been  completed. 

The  degree  to  which  subsystems  are  typically  designed  during  the 
CDP  and  PDP  was  identified  for  several  work  unit  code  (WUC)  levels. 
These  results  may  be  useful  in  the  future  to  identify  areas  and  levels 
of  hardware  design  activity  in  the  early  phases,  thereby  assisting  in 
determining  the  type,  level,  form,  and  content  of  HRD  that  may  be  use¬ 
ful  to  support  these  activities. 


TRADE  STUDIES 


The  161  survey  respondents  identified  3,778  representative  trade 
studies  accomplished  during  the  CDP,  PDP,  and  DDP.  Trades  were  ana¬ 
lyzed  within  each  design  phase  according  to  category  (conceptual, 
parametric,  design),  concept  (operational  concept,  support  concept, 
hardware  concept),  engineer  (PE,  DE,  ILS),  and  product  (fighter,  trans¬ 
port,  bomber,  avionics). 

More  than  80%  of  all  important  system  and  subsystem  level  trade 
studies  conducted  for  a  weapon  system  acquisition  program  are  conducted 
during  the  CDP  and  PDP.  Of  the  trades  conducted  in  the  CDP  and  PDP, 

22%  relate  to  high-level  conceptual  trades  early  in  the  CDP,  while  the 
other  78%  address  parametric  and  design  trades  that  relate  to  specific 
system  hardware  alternatives.  This  finding  clearly  shows  the  impor¬ 
tance  of  the  development  and  use  of  high-level  PER/CER  to  influence 
the  design  process.  0&S  HRR  (ground  support)  are  impacted  by  at  least 
70%  of  all  trades  in  the  CDP  and  PDP. 

Analyses  of  trade  studies  by  various  breakdowns  may  influence  the 
UDB  effort  in  terms  of  the  form/content  and  level  of  data  elements. 

For  example,  hardware  concepts  dominate  PE  and  DE  trade  studies,  while 
ILS  types  are  split  between  hardware  and  support  concept  trades.  Op¬ 
erational  trades  occur  early  in  the  process,  primarily  by  PEs  and  DEs. 
Support  concept  trade  studies  increase  as  the  design  process  progresses 
and  are  conducted  primarily  via  logistics  support  analyses.  Because 
PEs  and  DEs  are  primarily  concerned  with  hardware  concepts  and  greatly 
outnumber  ILS  engineers,  there  is  a  need  for  a  UDB  to  supply  all  engi¬ 
neers  with  HRD  to  influence  trade  studies  throughout  the  design  process. 

Another  factor  which  may  influence  the  UDB  effort  is  the  level  of 
trade  study  activity  between  products.  During  the  CDP  and  PDP,  the 
level  of  trade  studies,  and  thus  the  level  of  HRD  necessary  to  support 
the  studies,  between  products  is  relatively  constant.  Of  particular 
significance,  however,  is  that  fighter  aircraft  product  engineers  ac¬ 
complish  more  total  trade  studies  and  34%  more  hardware  trade  studies 
per  capita  than  do  other  product  type  engineers.  At  the  same  time. 
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fighter  types  accomplish  less  than  40%  of  the  per  capita  support 
concept  trades  done  by  other  product  type  engineers.  Thus,  while 
fighter  aircraft,  by  complexity  and  sheer  numbers,  represent  the  larg¬ 
est  HR  impact,  their  design  is  least  responsive  to  trade  studies 
involving  0&S  impacts. 


HUMAN  RESOURCES  FACTORS  };■ 

An  important  consideration  in  the  development  of  a  UDB  is  the  de- 
gree  to  which  human  resources  factors  (HRF)  are  considered.  Table  2  1  i 

shows  the  percentage  of  total  trade  studies  for  CDP/PDP  which  consider  jj 

a  particular  HRF. 

Reliability  and  maintainability  are  the  HRF  most  frequently  con-  ; 

sidered,  with  ground  support  equipment  (GSE)  and  ground  support  man-  j ■ 

power  costs  (MP  COST)  coming  in  a  distant  second.  Technical  data  and  ; 

built-in-test-equipment  (BITE)  are  the  HRF  considered  least  in  trade 
studies.  Many  HRF  are  considered  in  only  30%  of  the  trade  studies. 


TABLE  2.  CONSIDERATION  OF  HRF— 

PERCENTAGE  OF  TOTAL  TRADES 


HRF 

Trades 

Which  Consider 

a  HRF,  % 

DE 

PE 

ILS 

Total  % 

Reliability 

63.15 

71.63 

83.33 

70.78 

Maintainability 

68.08 

7^.47 

79.06 

72.05 

GSE 

36.04 

53.05 

57.83 

44.90 

BITE 

21.34 

32.91 

41.31 

28.54 

Task  Analysis 

24.03 

37.73 

42.74 

31.43 

Skills 

23.25 

35.46 

32.91 

28.25 

Skill  Level 

26.78 

33.62 

32.62 

29.68 

Crew  Size 

25.40 

44.68 

36.61 

32.37 

Training  Requirements 

29.23 

33.90 

33.48 

31.27 

Technical  Data 

24.81 

28.09 

32.76 

27.37 

Manpower  Costs 

41.42 

47.94 

65.38 

48.38 

Human  Factors 

35.68 

39.86 

34.33 

36.33 

Total  Number  of 

Trades  Considered 

1653 

705 

702 

3080 

Total  Number  of  Trades 
Impacting  HRR 

1079 

510 

579 

2291 

Percentage  of  Total 
Trades  that  Impact  HRR 

64.  5% 

72.  3% 

82.5% 

74.4% 

jj*.  . 
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To  a  significant  degree,  DE  consider  HRF  in  trade  studies  less 
frequently  than  do  PE  and  ILS.  It  is  surprising  to  note  that  PE  con¬ 
sider  skills,  skill  level,  crew  size,  training  requirements,  and  human 
factors  in  trade  studies  more  frequently  than  ILS.  It  is  also  surpris¬ 
ing  that  8  of  the  12  HRF  are  considered  in  less  than  43%  of  all  trade 
studies  by  ILS. 

In  the  3080  trade  studies  identified  for  CDP/PDP,  2291  (74%)  were 
judged  by  DE,  PE,  and  ILS  to  impact  HRR.  Thus,  it  is  seen  that  while 
individual  HRF  are  not  being  considered  in  the  majority  of  trade 
studies,  engineers  clearly  recognize  that  these  trade  studies  involve 
downstream  O&S  impact  on  HRR. 

The  importance  placed  on  each  HRF  during  a  trade  study  is  useful 
data  for  designing  UDB  data  elements.  In  addition  to  identifying  the 
HRF  actually  considered  in  trade  studies,  as  shown  in  Table  2,  the 
survey  engineers  also  identified  the  factors  they  considered  most  im¬ 
portant  in  each  trade  study.  While  187  discrete  factors  were  identi¬ 
fied,  the  top  15  account  for  over  50%  of  the  total  number  of  times  that 
all  important  factors  were  mentioned  for  all  trade  studies.  These  top 
15  important  factors  were:  weight/weight  allocation,  acquisition  cost, 
reliability,  maintainability,  subsystem  requirements,  system  perfor¬ 
mance,  R&M/availability ,  life-cycle  cost,  subsystem  design  concept, 
maintenance  requirements,  hardware  design/ performance  requirements, 
manpower  (number,  skills,  levels),  survivability/vulnerability,  support 
equipment,  support  concepts.  Eight  of  these  top  15  factors  are  HR 
related  and  account  for  22%  of  the  total  number  of  times  that  all  im¬ 
portant  factors  were  mentioned  for  all  trade  studies.  Thus,  it  is 
seen  that  while  some  HRF  rank  very  high  in  importance  for  all  trade 
studies,  others  such  as  BITE,  training  requirements,  and  technical  data 
are  rarely  considered  important.  There  is  an  apparent  contradiction  in 
the  level  of  importance  placed  on  skills,  skill  level,  crew  size  and 
C.SE,  and  the  degree  to  which  they  are  actually  considered  in  trade 
studies.  While  they  are  considered  among  the  top  most  important  fac¬ 
tors  to  be  considered.  Table  2  shows  that  they  are  actually  considered 
in  less  than  30%  of  the  CDP/PDP  trade  studies.  As  will  be  discussed 
later,  the  reason  appears  to  be  the  lack  of  timely  and  useful  data  in 
these  areas.  ..>■ 


SOURCES  OF  HRD 


When  HRF  are  considered  in  a  traue  study,  data  are  supplied 
generally  by  functional  organizations  only  when  requested  by  the  de¬ 
sign  team.  When  adequate  data  are  provided,  the  following  sources 
provide  them  96%  of  the  time:  company /suppor t  engineering  (66%) , 
Government/Air  Force  (14%),  design  engineering  (6%),  vendors  (6%), 
other  company  data  (4%).  Overall,  company  data  are  used  much  more 
frequently  than  are  AFLC  data;  however,  it  is  not  known  how  much  of  the 
company  data  are  obtained  from  the  AFLC  data  tapes. 

AVAILABILITY/ADEQUACY  OF  DATA 
FOR  USE  IN  WEAPON  SYSTEM  DESIGN 

Data  from  the  trade  study  analyses  were  combined  with  additional 
survey  data  to  evaluate  the  availability  and  adequacy  of  existing  HRD 
to  influence  system  design.  As  programs  evolve  through  CDP  and  PDP, 

HRF  are  increasingly  considered,  but  the  increase  is  relatively  small. 

Sixty-six  percent  of  all  ILS  engineers  stated  that  the  availabil¬ 
ity  of  HRD  for  use  in  all  RDT&E  is  limited  but  satisfactory.  Fighter 
aircraft  ILS  engineers  are  more  inclined  to  believe  data  availability 
is  satisfactory  than  are  other  product  type  engineers. 

Sixty-one  percent  of  all  ILS  engineers  stated  that  the  adequacy  of 
available  HRD  is  unsatisfactory.  Again,  fighter  aircraft  ILS  engineers 
disagree  with  the  other  product  type  engineers:  70%  indicate  the  ade¬ 
quacy  of  HRD  is  satisfactory.  It  should  be  noted  that  on  a  per  capita 
basis  fighter  aircraft  engineers  conduct  40%  fewer  support  concept 
trade  studies  than  do  the  other  product  type  engineers.  If  the  data 
are  not  used,  existing  inadequacies  will  not  be  recognized. 

Regarding  overall  adequacy  of  HRD  for  use  in  the  CDP,  52%  of  the 
PE  and  ILS  respondents  say  the  data  are  inadequate.  The  results  are 
generally  applicable  to  the  PDP  as  well. 

PROBLEMS  IN  USING  HRD  IN  CDP/PDP 

The  industry  respondents  specifically  stated  that  the  top  three 
major  problems  associated  with  using  HRD  to  influence  design  in  the  CDP 


are  (a)  lack  of  useful/usable  data,  (b)  insufficient  time,  funds, 
priority,  and  (c)  inadequate  design  definition.  In  the  PDP ,  the  top 
three  problems  are  (a)  lack  of  useful/usable  data,  (b)  company  organi¬ 
zation  and  attitudes  of  engineers,  and  (c)  limited  need  and  applica¬ 
bility  for  design.  Specific  industry  recommendations  to  correct  these 
problems,  listed  by  percentage  of  time  mentioned  are  (a)  general  and 
specific  HRD  improvements  (48%),  (b)  increased  government  (customer) 
emphasis  and  priority  (26%),  (c)  organizational/functional  responsi¬ 
bilities  (lJo),  and  (d)  education  and  training  of  engineers  (6%). 

ADEQUACY  OF  DATA  TECHNOLOGIES  (SURVEY) 

Of  93  DEs  responding,  76%  stated  a  preference  for  a  UDB  of  HRD  to 
provide  information  to  influence  design.  Regarding  the  required  use  of 
MIL-STD-1388  on  all  major  weapon  system  programs,  47%  of  all  respon¬ 
dents  approved,  19%  disapproved,  31%  did  not  know  and  3%  failed  to 
respond.  Regarding  improved  compatibility  between  LSAR  and  WUC,  52% 
of  the  industry  considers  this  desirable,  6%  undesirable,  13%  insig¬ 
nificant,  and  28%  either  having  no  opinion  or  failing  to  answer. 

All  respondents  were  asked  to  respond  to  a  question  regarding  mak¬ 
ing  the  work  breakdown  structure  (WBS)  more  compatible  with  the  WUC 
structure:  65%  of  respondents  favored  more  compatibility,  22%  dis¬ 

agreed  with  the  notion,  and  17%  did  not  answer. 

Several  disadvantages  tc  making  WBS  compatible  with  WUC  were 
listed  (in  order  of  decreasing  frequency):  administrative  and  organi¬ 
zation  problems  of  cost  accounting  and  management  control,  inherent 
incompatibility  of  WBS  and  WUC,  complexity  of  accounting  and  documen¬ 
tation  system,  resistance  to  changing  the  current  system,  difficulty  of 
using  historical  data  for  cost  estimating,  additional  cost  of  account¬ 
ing  systems,  and  negative  impacts  on  design  and  technical  areas.  In 
spite  of  these  disadvantages,  the  industry  respondents  appear  to  be 
highly  in  favor  of  greater  WBS/WUC  compatibility.  Advantages  to  this 
sort  of  system  fall  into  these  major  categories:  better  correlation  of 
design  effort  to  system  performance,  better  cost  estimating/control/ 


accountability,  utility  of  historical  data,  greater  system  commonality, 
and  improved  LCC  estimating  and  trackability . 

RECOMMENDATIONS  TO  RESOLVE  PROBLEMS  IN  USING  HRD 

The  DE  and  ILS  engineers  were  asked  to  "Provide  any  suggestions/ 
recommendations  you  may  have  to  help  resolve  the  problems  associated 
with  utilizing  HRD  in  the  conceptual  and  preliminary  design  phases." 

Customer  (Government)  Emphasis  and  Priority 

Some  of  the  more  significant  suggestions/recommendations  fall  in 
the  area  of  "Customer  (Government)  Emphasis  and  Priority,"  and  are 
included  here  because  of  their  importance  to  the  future  development  of 
a  UDB. 

1.  "A  company  could  afford  to  address  this  problem  only  if  it 
were  sure  all  competitors  were  also  going  to  be  forced  to  spend  the 
time  and  money  considering  O&S  manpower  requirements  and,  where  neces¬ 
sary,  compromising  their  design  because  of  it.  Merely  making  accurate 
HRD  readily  available  would  not  be  enough.  Specification  requirements 
would  have  to  force  it." 

2.  "HRF  must  be  given  as  much  weight  as  other  factors  in  the 
evaluation  of  a  contractor's  performance.  Because  of  budget,  enough 
money  is  never  available  to  do  everything  that  should  be  done  and  HRF 
considerations  take  second  place  to  aircraft  basics." 

3.  "Resolution  is  of  course  to  make  the  objective  of  reliable, 
maintainable,  and  reasonable  LCC  a  reality  that  is  visible,  emphasized, 
and  paid  for.  When  such  efforts  are  asked  for  but  their  cost  is  effec¬ 
tively  used  against  the  bidding  firm  in  the  price  competition,  then 
their  position  is  really  subordinated  to  performance  and  no  actual  HRD 
except  the  minimum  is  involved." 

4.  "O&S  requirements  should  be  integrated  from  the  beginning 
with  those  for  the  design  evaluation  and  development  process;  e.g., 
design,  stress,  loads,  tooling,  test,  etc." 

5.  "Provide  specific  requirements  for  HRD  and  to  what  extent 
performance,  weight,  safety  and  R  can  be  compromised  to  meet  HRD  re¬ 
quirements.  In  most  cases  these  requirements  will  he  in  conflict." 
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6.  "Top  level  DOD/AF  emphasis  on  design-to-cost  (DTC)  and  LCC 
and  related  publicity  will  help,  particularly  if  contracts  are  some¬ 
times  awarded  to  the  apparent  high  bidder  based  on  a  significantly 
lower  O&S  cost.  On  contracted  studies,  the  problem  can  be  resolved  by 
including  appropriate  support  tasks  in  the  statement  of  work." 

7.  "Air  Force  must  follow  through  with  support  planning  in  the 
conceptual  phase.  Funding  must  be  provided  and  sustained  for  this  pur¬ 
pose.  Current  policy  involves  allocating  funds  for  both  O&S  systems. 
Support  funds  are  always  transitioned  to  the  operational  system  devel¬ 
opment  effort." 

8.  "Expressed  willingness  by  DOD/AFLC  to  invest  their  resources 
in  support  earlv-on  coupled  with  AFALD  participation  will  help.  Firm 
requirements  in  the  statement  of  work  will  fix  it  for  sure." 

These  suggest ions/recommendat ions  appear  to  best  represent  the 
consensus  of  the  industry.  Responses  generally  indicate  that  the  cus¬ 
tomer  must  incorporate  into  procurement  documentation  the  requirements 
and  f unds  to  consider  HRD  in  the  CDP  and  PDP.  Until  this  is  effectively 
accomplished,  there  is  simply  no  incentive,  opportunity,  or  advantage 
to  the  contractor  for  attempting  to  effectively  incorporate  the  use  of 
HRD  in  early  design  decisions.  Moreover,  the  DTC  requirements,  if 
imposed,  may  require  design  decisions  to  drive  acquisition  costs  down 
while  simultaneously  driving  ultimate  O&S  costs  up.  These  potentially 
opposing  objectives  (i.e.,  lower  DTC  and  lower  O&S  costs)  must  be 
recognized  and  balanced  by  the  customer. 

General  Improvement  of  HRD 

The  second  most  significant  area  addressed  falls  in  the  category 
of  "General  Improvement  of  HRD."  The  following  comments  are  presented 
here  because  of  their  potential  value  in  the  selection  of  data  genera¬ 
ting  technology  to  be  incorporated  into  the  DGTB.  These  comments 
strongly  support  the  need  for  a  dramatic  increase  in  CER/PER  to  support 
the  design  process. 

1.  "Estimating  or  computational  techniques  used  for  HRD.  Con¬ 
ceptual  phase  values  must  be  sensitive  to  design/performance  parameters 
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used  consistently  during  CDP  and  PDP.  In  addition,  the  technique  must: 

a.  provide  realistic  values  that  can  be  achieved  and 
demonstrated  in  actual  operational  units,  and 

b.  respond  to  design  technology  improvements,  simpli¬ 
fied  installations,  and  planned  access  provisions.  The  only 
difference  between  the  two  phases  (conceptual/preliminary 
design)  is  that  the  design/performance  parameters  can  usually 
be  identified  to  the  subsystem  level  during  preliminary  design 
and  are  usually  better  defined." 

2.  "Fund  studies  to  correlate  data  available  through  AFM  66-1  to 
performance  and  equipment  design  characteristics.  Make  results  avail¬ 
able  to  all  contractors.  Expand  data  available  in  AFLC  Pamphlet  800-4 
to  include  all  WUCs  to  five  digit  level.  Make  data  available  to  all 
contractors  with  a  need  to  know." 

3.  "If  studies  could  be  done  of  existing  weapon  systems,  using 
the  quality  of  design  available  at  their  inception,  then  these  esti¬ 
mated  HRD  could  be  compared  to  actual  manhour  expenditures.  If  reason¬ 
able  correlation  is  obtained,  these  results  could  be  used  to  gain 
credibility." 

4.  "I  think  if  someone  could  compile  a  set  of  basic  system 
descriptions  that  would  characterize  all  of  the  essential  elements  of  a 
system  that  related  to  HRD,  so  a  designer  could  establish  similarity 
for  whatever  phase  he  is  in,  and  then  compile  prediction/analysis  and 
field  data  for  those  systems,  and  put  the  information  in  some  sort  of 
form  where  it  was  immediately  accessible,  that  tremendous  improvements 
would  result." 

5.  "Inadequate  Technology:  More  research  is  required  into  the 
failure  modes  of  aircraft  equipment,  the  environmental  cause  of  fail¬ 
ures  and  design  parameters  or  details.  Likewise,  more  research  is 
required  into  the  exact  nature  of  maintenance  actions  and  design  char¬ 
acteristics.  For  many  systems,  as  much  time  is  consumed  in  diagnostic 
activities,  no  removals,  and  minor  repairs  as  is  spent  on  repair  of 
relevant  failures." 
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6. 


"Stress  placed  upon  performance:  The  relationships  between 


operational  readiness,  sortie  capability,  and  success  of  combat  mission 
should  be  established  early  in  the  design  stage.  Parametric  relation¬ 
ships  must  be  used  if  appropriate  trade-offs  between  R,  M,  and  conven¬ 
tional  performance  parameters  are  to  be  accomplished.  Further,  these 
considerations  should  be  incorporated  in  all  DTC  trades." 

New/ Improved  HRD 

The  following  comments  are  from  specific  recommendations  for  new/ 
improved  HRD: 

1.  "Data  that  would  permit  maintenance  cost  at  an  early  stage, 
if  it  could  be  generated  in  a  believable  fashion,  would  help  increase 
the  impact  on  design  decisions  at  an  early  stag^.  However,  such  data 
needs  to  be  believable.  Today,  even  in  the  operational  phase,  the 
O&S  cost  projections  used  for  value  engineering  studies  is  constantly 
being  questioned,  often  by  the  people  that  generate  the  data." 

2.  "Maintenance  manhours/flight  hour  (MMH/FH)  for  various 
systems — sufficient  to  give  relative  indicators  on  aircraft  weight, 
crew  size,  number  of  engines,  density  of  packaging,  avionics  equipment, 
armament  (number  of  store  stations),  pod  mounted  v  .sus  buried  engines, 
fixed  versus  variable  swept  wing,  integral  fuel  tanks  versus  bag 
(bladder)  tanks.  Publishing  data  on  existing  systems  with  analysis 
identifying  prime  drivers  for  difference  between  similar  systems  would 
be  extremely  helpful." 

3.  "At  the  total  system  level,  it  would  be  desirable  to  have 
reasonable  HRD  information  when  almost  no  detail  of  the  system  is 
known.  There  are  routines  that  will  give  program  prices  when  all  that 
is  known  is  weight,  speed,  number  of  units  to  be  procured,  engine 
thrust,  number  of  engines  and  fuel  load  are  inputed.  A  similar  HRD 
estimate  would  upgrade  LCC  estimates  at  this  early  stage  of  a  program." 

4.  "A  specific  conceptual  phase  computer  program  which  would 
allocate  statistical  R&M  parameters  among  the  major  air  vehicle  ele¬ 
ments  and  subsystems  as  a  function  of  design  parameters  known  at  that 
time  which  is  sensitive  to  concept  variations.  The  allocation  buildup 
to  be  printed  out  for  analysis,  as  weights  and  costs  are  now." 


5. 


"Sensitivity  data  for  O&S  costs  as  they  vary  for  changes  in 


significant  weapon  system  performance  parameters,  such  as  gross  weight, 
speed,  range,  number  of  engines,  etc.  Even  qualitative  data  to  guide 
the  concept  analyst  during  early  trades." 

6.  "A  computer  model  that  provides  O&S  costs  or  variations  in 
cost  as  a  function  of  major  weapon  system  performance  parameters  or 
basing  concepts." 

7.  "Need  trade-off  tables  or  curves  to  show  O&S  and  LCC  impact 
on  manpower  requirements  as  a  function  of  the  number  of  LRU,  SRU ,  and 
hardware/ sof tware  partitioning." 

8.  "A  graphic  illustration  that  indicates  in  some  manner  the 
relationship  between  system  tolerances,  complexity,  percentage  new 
development,  etc.;  such  that  systems  under  consideration  can  be  plotted 
to  obtain  relative  merit  and  risk  for  each  alternate." 

9.  "A  chart  or  series  of  charts  (nomograms)  that  allow  gross 
trades  in  a  given  system  between  performance  requirements,  R,  M, 
initial  costs,  and  LCC." 

10.  "Historical  data  on  MMH/FH  (total  weapon  system,  system  and 
subsystem)  versus  availability,  O&S  cost  plus  any  other  M  quantitative 
parameters  that  relate  to  performance  and  cost.  HRD  is  needed  that  can 
establish  credible  relationships  between  actual  M  requirements,  opera¬ 
tional  availability  (Aq)  ,  and  O&S  real-world  results." 

Here  again,  the  recommendations  are  representative  of  the  overall 
consensus  of  the  industry  as  to  the  type  of  HRD  most  needed  to  support 
CDP  and  PDP  trade  studies  with  emphasis  on  CERs  and  PERs. 


SECTION  III 


CONCEPT  OF  UDB/DGTB 

GENERAL 

This  section  describes  the  concept  of  a  UDB  and  a  unified  DGTB. 
Section  IV  provides  an  overview  of  the  weapon  system  design  process  and 
how  the  UDB  and  DGTB  could  be  utilized  to  support  all  phases  of  an  air¬ 
craft  weapon  system  acquisition  program.  It  is  emphasized  that  the 
concept  of  the  UDB  and  DGTB,  as  discussed  in  this  section,  is  broader 
in  scope  than  the  specific  prototype  development  effort  recommended  in 
Section  V.  The  purpose  of  discussing  the  broader  concepts  of  a  UDB  and 
DGTB  is  to  insure  that  the  prototype  development  effort  provides  the 
appropriate  foundation  and  framework  upon  which  future  development  ef¬ 
forts  may  be  accomplished  in  a  modular  or  building  block  manner. 

PURPOSE  AND  OBJECTIVES 

The  UDB  and  DGTB  can  be  thought  of  as  two  separable  but  closely 
interrelated  data  bases.  It  is  very  important  to  understand  the  pur¬ 
pose  and  objectives  of  each  and  how  they  are  interrelated. 

PURPOSE  OF  DGTB 

The  primary  purpose  of  the  DGTB  is  to  provide  a  means  whereby  use¬ 
ful  and  usable  HR  information  can  be  brought  to  bear  so  as  to  influence 
the  design  process,  primarily  during  the  conceptual  and  validation 
phases  of  a  weapon  system  acquisition  program.  Thus  the  DGTB  is  basi¬ 
cally  a  "design  tool"  -  a  mechanism  to  provide  HR  related  information 
to  support  trade  studies  and  design  decisions  during  the  conceptual  and 
preliminary  design  stages.  The  information  provided  through  the  DGTB 
will,  as  a  function  of  trade  study  alternatives,  predict  O&S  HRR  (lo¬ 
gistics  related).  The  objective  of  the  designer,  in  using  the  DGTB, 
will  be  to  consider  the  impact  of  a  design  decision  on  O&S  HR  and 
logistic  support  requirements. 
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PURPOSE  OF  UDB 


The  primary  purpose  of  the  UDB  is  to  provide  a  consistent  and 
trackable  information  record  for  a  particular  weapon  system  as  it  pro¬ 
gresses  through  the  acquisition  process.  The  information  contained  in 
the  UDB  for  a  given  weapon  system  will  be  HR&LS  related.  The  UDB  will 
contain  standard  data  elements,  thus  permitting  systematic  analysis  and 
documentation  throughout  the  design/development,  production,  test,  and 
evaluation  process  for  a  weapon  system. 

Objectives  of  UDB 

The  UDB  is  intended  to  satisfy  three  major  objectives.  The  first 
is  to  provide  a  means  whereby  the  HR&LS  information,  that  evolves  dur¬ 
ing  the  weapon  system  design  process,  can  be  developed  in  a  consistent 
building  block  manner.  This  should  significantly  improve  the  continu¬ 
ity  and  compatibility  of  the  data  base  to  support  multiple  logistics 
efforts  during  acquisition.  It  should  also  reduce  duplication  of  ef¬ 
fort,  improve  planning  and  cost  estimates,  and  result  in  greater  system 
effectiveness. 

The  second  major  objective  of  the  UDB  is  to  provide  a  single 
thread  of  HR&LS  related  information  that  will  provide  a  consistent  au¬ 
dit  trail  from  the  CDP  through  the  O&S  phase  of  a  weapon  system  program. 
This  would  permit  trackability  of  the  UDB  from  initial  predictions  in 
the  CDP,  to  allocated  requirements  during  validation  and  full-scale 
development  (FSD)  phases,  to  the  demonstrated  results  during  operation¬ 
al  test  and  evaluation  (OT&E)  during  production  and  early  deployment, 
and  finally  to  the  field  data  collected  in  the  O&S  phase  of  the  weapon 
system.  This  single  thread  enables  the  Government  and  industry  to 
realistically  determine  how  well  a  weapon  system  met  its  objectives, 
and  will  improve  cost-effective  planning  for  the  O&S  phase  of  the 
weapon  system. 

The  third  major  objective  of  the  UDB  will  be  to  provide  a  source 
of  information  for  use  in  future  weapon  system  acquisition  programs. 

If  a  future  weapon  system  is  similar  to  the  one  for  which  a  UDB  exists, 
the  use  of  such  a  UDB  will  provide  an  invaluable  source  of  experience 
data  to  support  design  decisions  for  the  future  weapon  system. 
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Thus  it  is  seen  that  the  DGTB  provides  information  to  help  make 
knowledgeable  and  sound  decisions  throughout  the  design  process  for  any 
given  weapon  system.  The  UDB  records  relevant  information  related  to 
these  decisions  for  a  particular  weapon  system,  assists  in  planning, 
helps  to  eliminate  duplication  of  effort,  provides  an  audit  trail,  and 
provides  experience  data  for  use  in  future  acquisition  programs. 


INTERRELATIONSHIPS 

i 

The  interrelationship  between  the  UDB  and  DGTB  will  now  be  dis- 

i 

cussed.  As  stated  above, the  DGTB  is  basically  a  "design  tool"  to  sup¬ 
port  the  design/decision-making  process  for  any  given  weapon  system  ! 

under  development.  As  such,  it  must  be  developed  so  as  to  be  generic 
in  nature.  Otherwise,  it  would  be  necessary  to  develop  a  DGTB  for  each 

new  weapon  system  acquisition  program.  The  DGTB  will,  therefore,  con-  1 

tain  standard  programs,  and  techniques  to  retrieve  data  from  various 
existing  data  systems,  process  the  data  as  required,  and  provide  out¬ 
puts  to  users  as  needed.  In  addition,  the  DGTB  will  contain  selected 
data-generating  technology  programs  and  files  to  provide  specific  data 
to  users  as  needed.  The  DGTB  will  not  be  a  historical  data  base,  per 
se.  it  will  provide  storage,  as  required,  only  for  new  data  generated, 
but  it  will  not  duplicate  existing  historical  data  base  capabilities 
and  functions. 

Since  the  DGTB  is  generic  in  nature,  it  will  not  store  data  f or  a 
particular  weapon  system.  The  UDB  provides  the  means  whereby  users  can 
input  weapon  system  data  to  be  operated  upon  by  specified  programs  in 
the  DGTB  to  satisfy  user  requirements.  This  will  include  programs  for 
processing  LSAR  data,  providing  data  to  feed  other  programs  such  as 
LCOM,  Optimum  Repair  Level  Analysis  (ORLA) ,  AFLC  interfacing  systems, 
etc.  The  outputs  of  the  DGTB  must,  therefore,  be  consistent  and  com¬ 
patible  with  the  UDB  data  elements.  When  a  Systems  Program  Office 
(SPO)/Air  Force  Acquisition  Logistics  Division  (AFALD) /contrac tor  makes 
a  design  decision  that  involves  HR&LS  factors,  relevant  information 
regarding  same  will  be  stored  in  the  UDB. 

It  is  assumed  that  operational  responsibility  for  the  UDB  and  DGTB 

will  be  assigned  to  AFALD.  Since  both  systems  will  share  common 
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hardware  and  software,  the  UDB  and  DGTB  essentially  constitute  separ¬ 
able  parts  of  a  single  system.  Figure  1  shows  the  concept  of  the  UDB 
and  DGTB  in  terms  of  the  basic  system  components,  objectives,  functions 
and  interrelationships.  Note  that  a  UDB  file  would  be  established  for 
each  weapon  system  under  development.  A  detailed  schematic  and  flow 
diagram  of  the  UDB/DGTB  operational  concept  is  presented  in  Section  IV. 

DESCRIPTION  OF  DGTB 

The  DGTB  will  provide  standardized  procedures  for  compiling  his¬ 
torical  data  for  specific  applications  and  support  in  the  system  design 
process.  In  addition,  the  DGTB  will  contain  programs  which  represent 
the  best  and  most  efficient  techno  logics  to  support  all  stages  of  sys¬ 
tem  design.  The  historical  data  bases  and  data  generating  technologies 
will  be  identified  from  the  results  of  the  Clemson  study  (Thomas  and 
Hankins,  1980)  and  from  further  literature  research  during  the  early 
phase  of  the  prototype  UDB/DGTB  effort.  It  is  envisioned  that  the  DGTB 
will  ultimately  include  procedures  and  techniques  for  estimating  a  wide 
range  of  HR  requirements  as  a  function  of  design  alternatives  during 
the  GDP,  PDP,  and  DDP  of  any  given  weapon  system.  For  example,  the 
DGTB  would  ultimately  provide  the  capability  to  establish  initial  esti¬ 
mates  for  training,  job  guide,  skills,  skill  levels,  task  times,  per¬ 
sonnel  costs,  support  equipment,  tools,  and  training  equipment  require¬ 
ments  as  a  function  of  design  alternatives  in  a  particular  design  stage 
of  a  tighter,  bomber,  transport,  or  training  aircraft  system  in  RDT&E. 
The  extent  to  which  the  prototype  DGTB  will  provide  these  capabilities 
will  depend  on  (a)  the  extent  to  which  existing  historical  data  can  be 
utilized,  (b)  the  extent  to  which  existing  IX.'T  have  been  developed,  and 
(c)  the  constraints  of  time  and  resources  for  the  prototype  development 
and  effort. 

DATA  GENERATING  TECHNOLOGIES 
LCOM/CDEP 

l .COM  will  become  an  integral  part  of  the  DGTB  technologies  and 
capabilities,  as  will  the  common  data  extraction  programs  (CPEP) .  The 
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data  base  that  has  been  developed  for  use  by  LCOM  will,  to  the  maximum 
extent  possible,  be  utilized  by  the  DGTB.  It  appears  that  it  will  be 
necessary  to  reformat  the  input  of  LCOM  for  consistency  with  the  LSAR 
format  of  MIL-STD-1388. 

Other  Data  Generating  Technologies 

The  DGTB  will  incorporate  the  use  of  other  technologies  such  as 
CER,  PER,  method  for  evaluating  Aq,  method  for  adjusting  manpower  re¬ 
quirements  for  weapon  system  utilization  level,  method  of  assessment 
and  optimization  of  inspection  requirements,  and  a  method  for  construc¬ 
ting  multiple  regressions  into  nomograph  form  that  can  be  used  in 
design  trades. 

MAJOR  FUNCTIONS  OF  DGTB 

The  major  functions  of  the  DGTB  are  as  follows: 

1.  Retrieves  source  data  from  existing  data  systems. 

2.  Processes  data  in  a  systematic,  uniform,  and  consistent 
manner;  for  example,  the  CDEP. 

3.  Processes  source  data  so  as  to  provide  outputs  in  standard¬ 
ized  form  and  content  for  specific  putposes;  i.e.,  R&M  parameters  for 
the  purpose  of  conducting  R&M  impact  trade  studies  for  different  de¬ 
sign  approaches  (parameters  consistent  with  ARF  80-5  terms). 

4.  Provides  data  on  call  to  authorized  recipients. 

5.  Provides  generic  standardized  design/performance  character¬ 
istics  data;  i.e.,  AFR-2  type  data. 

6.  Provides  standardized  data  processing  and  storage  of  new  data 
for  input  to  the  "specific"  UDB;  i.e.,  LSAR  data. 

7.  Provides  Generic  CERs/PERs  for  specific  estimates;  i.e., 
initial  spares  cost  -  the  estimating  equations  and  parameters  would  be 
output  -  the  users  would  use  their  own  parameter  values  to  derive  an 
estimate. 

8.  Provides  file  maintenance  and  up-date  programs. 

9.  Provides  regression  analysis  program  -  available  on  demand 
for  use  by  authorized  users  to  operate  on  their  own  data  file  or  from 
data  provided  from  existing  data  systems. 
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10.  Provides  interfacing/processing  programs  for  AFLC  data  sys¬ 
tems  such  as  D-195,  D-220,  etc. 

11.  Provides  a  standardized  methodology  for  the  selection  of 
systems,  subsystems  to  be  used  as  the  historical  baseline  for  proposed 
new  equipment  and  performing  the  comparability  analysis  -  some  may 
(will)  be  standardized  and  will  consistently  and  systematically  be 
followed  each  time  a  comparability  analysis  is  performed. 

12.  Provides  certain  Air  Force  data,  such  as  job  descriptions  for 
maintenance  Air  Force  specialty  codes,  and  functional  application  for 
the  specialty  code;  i.e.,  pneudraulics ,  autopilot,  mechanical  acces¬ 
sories  repair,  fuel  cell  repair,  etc. 

13.  Another  consideration  might  be  to  have  certain  computer 
capability  at  the  user  site,  in  conjunction  with  the  remote  terminal, 
where  the  users  could  input  their  own  historical  data  (AFLC  data  for 
example)  and  call  up  the  programs  from  the  generic  data  base  to  operate 
on  the  data.  This  approach  would  still  provide  standard,  consistent, 
and  uniform  data  to  support  RDT&E  in  that  the  programs  used  to  process 
the  data  provide  the  uniformity  and  consistency.  The  R&M  data  provided 
in  the  AFALDP  800-4  are  a  good  example.  The  format  in  which  the  data 
are  presented  breaks  out  into  inherent,  induced,  no-defect,  and  total  - 
then  both  the  events  and  manhours  are  broken  out  by  organization  level 
(line)  and  intermediate  level  (shop).  The  program  that  processed  those 
data  has  the  decision  logic  built  in  to  make  the  Dreakouts  displayed. 
Therefore,  any  time  R&M  data  are  required  from  historical  data  the 
output  is  consistent  in  the  segregation  of  the  events  and  manhours  and 
conforms  to  AFR  80-5  program  management  terms  for  R&M  parameters. 

DESCRIPTION  OF  THE  UDB 

The  UDB,  or  specific  weapon  system  data  base,  is  the  information 
record  that  evolves  during  the  design  process  for  a  given  weapon  system 
program.  The  UDB  will  contain  HR  related  estimates  and  characteristics 
of  the  weapon  system,  and  will  utilize  MIL-STD-1388,  LSA  and  the  re¬ 
sulting  LSAR  as  the  major  source  of  data  elements.  However,  other 
relevant  weapon  system  information  will  be  a  necessary  part  of  the  UDB. 
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CONCEPTUAL  PHASE 


Initially  (in  the  CDP) ,  the  UDB  may  contain  specified  program 
requirements,  specified  goals,  basic  O&S  concept  data,  top  level  design 
parameters  (gross  weight,  speed,  range,  payload,  etc.),  and  other  data 
that  may  be  relevant  to  O&S  ground  support  HR  requirements.  As  concep¬ 
tual  design  progresses  and  system  definition  evolves,  information  filed 
in  the  UDB  will  expand  accordingly.  By  the  end  of  the  CDP,  the  initial 
system  specification  (functional  baseline)  for  the  vea  'on  system  will 
have  been  established/documented,  and  the  initial  baseline  of  HR&LS 
information  will  be  stored  in  the  UDB.  To  a  large  extent,  these  data 
will  be  high  level  parametric  estimates  of  HR&LS  requirements.  These 
high  level  parametric  estimates  are  predictions  of  the  weapon  system 
performance  and/or  requirements  in  terms  of  R&M  manpower,  training, 
training  aids,  support  equipment,  costs,  etc.  during  the  O&S  phase. 

VALIDATION  PHASE 

r 

As  the  weapon  system  progresses  into  the  PDP  (validation  phase), 
the  UDB  continues  to  expand  as  the  level  of  detail  of  the  weapon  system 
design  definition  increases.  The  UDB  will  continue  to  file  the  earlier 
baseline  information  and  will  build  upon  those  data  at  the  subsystem 
levels.  LCOM  outputs  will  be  stored  in  the  UDB  as  they  become  avail¬ 
able.  As  the  LSA  increasingly  comes  into  play,  the  outputs  are  stored 
in  the  UDB.  All  of  the  UDB  information  will  be  compatible  and  consis¬ 
tent  to  permit  optimum  utilization  and  avoid  duplication  of  effort. 

FULL-SCALE  DEVELOPMENT  PHASE 

The  UDB  is  expanded  to  its  full  level  of  detail  as  the  weapon 
system  progresses  through  DDP  (full-scale  development)  and  detailed 
LSARs  are  input.  At  this  time,  more  detailed  training,  training  equip¬ 
ment,  job  guide  (technical  data),  support  equipment,  and  ORLA  require¬ 
ments  are  filed.  As  the  UDB  continues  to  mature,  it  provides  a  history 
for  future  procurement,  from  concept  to  deployment,  in  consistent/ 
compatible  data  elements. 
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SECTION  IV 


CONCEPT  OF  OPERATION 

GENERAL 

This  section  presents  the  manner  in  which  the  UDB/DGTB  would  be 
utilized  during  RDT&E  of  a  new  weapon  system.  An  overview  of  the 
weapon  system  design  process  is  presented  in  the  context  of  how,  when, 
and  why  the  UDB/DGTB  would  be  utilized  by  those  involved  in  the  acqui¬ 
sition  process. 


SINGLE  POINT  MANAGEMENT 

As  a  new  aircraft  weapon  system  program  progresses  through  the 
CDP,  validation,  and  full-scale  development  phases,  the  Aeronautical 
Systems  Division  (ASD)  is  assigned  single  Air  Force  management  respon¬ 
sibility  for  all  aspects  of  the  RDT&E  program.  During  these  program 
phases,  the  weapon  system  progresses  through  the  CDP,  PDP,  and  DDP ,  and 
essentially  all  development,  fabrication,  assembly  and  testing  (Cate¬ 
gories  I  and  II)  are  completed.  Throughout  this  period,  however,  many 
organizations  exert  strong  influence  on  the  destiny,  design,  schedule, 
and  cost  (LCC)  of  the  weapon  system.  Figures  2,  3,  and  4  show  the 
UDB/DGTB  system  elements,  basic  input/output  relationships,  and  system 
users  as  a  function  of  the  CDP,  PDP,  and  DDP,  respectively. 

PRE-CONCEPTUAL  PHASE 

Initially  the  ASD  SPO  cadre  prepares  a  Mission  Element  Need  State¬ 
ment  (MENS).  This  is  a  oordinated  effort  with  support  from  Air  Force 
laboratories,  AFLC,  operational  commands  (OP  CMD) ,  and  others.  Prior 
to  the  program  initiation  decision  (DSARC  0),  ASD,  with  support  from 
the  AFALD,  may  utilize  the  UDB/DGTB  central  data  processor  to  selec¬ 
tively  analyze  AFLC  historical  data  (Figure  2)  for  comparison  with  top 
level  planning  data  to  identify  mission  requirements  and  manpower, 
support,  and  cost  constraints. 
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UNIFIED  DATA  BASE  (EVOLVING  NEW  WEAPON  SYSTEM!  AND 
DATA  GENERATING  TECHNOLOGY  DATA  BASE  -  CONCEPTUAL  OVERVIEW 
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CONCEPTUAL  PHASE 


After  DSARC  0,  ASD  will  explore  alternative  system  approaches  to 
satisfy  the  MENS  and  established  constraints.  An  overview  of  the  CDP 
is  presented  in  Figure  2. 

BASELINE  UDB 

At  this  point,  the  selection  of  the  current  operational  system(s) 
to  be  used  for  establishing  the  historical  baseline  for  the  evolving 
new  weapon  system  would  be  made.  The  required  data  would  be  retrieved 
from  existing  data  systems  and  stored  in  the  UDB.  These  data  on  cur¬ 
rent  operational  system(s),  which  most  closely  resemble  the  new  evolv¬ 
ing  weapon  system,  will  be  used  for  comparability  analyses  and  to 
initialize  the  UDB  for  the  new  weapon  system. 

In  addition  to  the  historical  data  for  use  in  establishing  the 
baseline,  other  pertinent  information  is  also  required  to  initially 
define  the  UDB.  As  currently  envisioned,  the  following  data  files  are 
examples  of  data  that  would  establish  the  UDB  in  the  early  stages  of 
the  CDP  of  a  new  weapon  system  development  program: 

.  Operational  scenario  (operational  concept,  number  of 
aircraft,  number  of  bases,  utilization  or  sortie  gen¬ 
eration  rate,  for  both  peacetime  and  wartime  operation, 
etc.,  unless  classified). 

.  Design  and  performance  characteristics  (weight,  speed, 

range,  altitude,  payload)  goals  or  "design  to"  require¬ 
ments. 

.  Maintenance  and  support  concepts. 

.  System  readiness  goals. 

.  R&M  (including  built-in  test  equipment,  if  applicable) 

parameters  critical  to  system  readiness  and  support 
cost. 

.  Limited  scheduling  information  (to  be  defined  during 
prototype  UDB/DGTB  development). 

.  Maintenance  and  support  cost  data  on  current  system(s) 
used  to  establish  baseline  and  perform  trade  studies. 
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Other  requirements  that  may  be  identified  in  the  proto¬ 
type  UDB/DGTB  development  effort. 

HISTORICAL  DATA  SOURCES 

The  sources  for  retrieval  of  the  historical  data  for  use  in  estab¬ 
lishing  the  historical  baseline  and  for  performing  trade  studies  will 
be  finalized  during  the  early  phase  of  the  UDB/DGTB  development  effort. 
Specific  sources  to  be  considered  will  be  as  follows: 

MDCS. 

.  Base  Level  Maintenance  Cost  System. 

.  Visibility  and  Management  of  Support  Costs  (VAMOSC) . 

.  Operational  Support  Cost  Reports  (OSCR) . 

.  Supply  data  will  be  needed  but  source  must  be  determined 
later. 

.  USAF  Cost  and  Planning  Factors  (AFR  173-10). 

.  Others  that  may  be  identified  in  the  UDB/DGTB  develop¬ 
ment  effort. 

USE  OF  DGTB 

Conceptually  the  DGTB  would  include  some  programs  designed  to  sup¬ 
port  the  LSA  process  by  operating  on  the  data  stored  in  the  UDB.  Other 
programs  in  the  DGTB  would  operate  on  data  stored  in  the  DGTB  to  gen¬ 
erate  input  data  to  the  UDB.  Still  other  programs  in  the  DGTB  would 
retrieve  and  operate  on  data  from  existing  data  systems  for  use  in  the 
LSA  process,  and  to  interface  with  technologies  such  as  LCOM.  In  any 
case,  use  of  the  DGTB  would  be  to  perform  the  following  support  func¬ 
tions,  as  examples: 

.  Utilize  existing  PERs  and  CERs. 

.  Develop  new  PERs  and  CERs. 

.  Accomplish  design  trade  studies  and  analyses. 

.  Perform  ORLA 

.  Establish  initial  estimates  for  LSAR  data  elements. 

.  Assess  impacts  for  variable  levels  of  utilization. 

.  Assess  inspection  requirements. 
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Assess  operational  availability. 

Others  that  may  be  identified  in  the  UDB/DGTB  develop¬ 
ment  effort. 


Throughout  the  CDP,  ASD/AFALD  will  use  the  UDB/DGTB  to  initialize 
the  UDB  and  input  baseline  historical  data  for  comparability  analyses. 
The  DGTB  will  provide  top  level  PERs/CERs  to  support  the  initial  LCC 
estimates.  As  the  CDP  progresses,  the  top  level  system  specification 
is  established,  and  the  baseline  for  the  evolving  system  is  input  to 
the  UDB. 

INDUSTRY  USE  OF  UDB/DGTB 

During  the  CDP,  the  ASD  will  solicit  and  obtain  industry  partici¬ 
pation  in  the  initial  weapon  system  concept  identification  and  defini¬ 
tion.  ASD/AFALD  would  utilize  the  UDB/DGTB  system  to  establish  system 
level  requirements  and  goals  relevant  to  HR&LS  requirements.  These 
requirements  and  goals  will  be  stored  in  the  UDB  at  this  point. 

The  aerospace  contractor  begins  to  exert  a  strong  influence  on  the 
destiny,  design,  schedule,  and  cost  of  a  weapon  system  after  contract 
award.  Remote  access  to  the  UDB/DGTB  enables  the  contractor  to  re¬ 
trieve  selected  AFLC  historical  data,  conduct  comparability  analyses, 
and  develop  the  initial  system  specification  and  UDB  baseline.  As  con¬ 
ceptual  and  parametric  trade  studies  are  conducted,  the  contractor  will 
utilize  the  DGTB  to  support  these  efforts.  For  example,  at  this  point, 
various  system  concepts,  configurations,  and  parameters  are  investiga¬ 
ted,  and  the  initial  weapon  system  data  (operational  scenario,  support 
concept,  weight,  range,  speed,  payload,  etc.)  have  been  input  to  the 
UDB.  Using  this  baseline,  the  contractor  will  utilize  the  DGTB  to  re¬ 
trieve  and  process  historical  data  to  be  used  for  the  comparability 
analyses  and  establishment  of  the  initial  system  data  base  which  is 
stored  in  the  UDB  in  the  form  of  initial  LSARs  (system  level).  The 
DGTB  is  also  used  to  operate  on  the  historical  data  to  generate  new 
data  such  as  CERs  and  PERs.  The  DGTB  would  also  be  used  to  provide  LCC 
Inputs  to  support  program  management  decisions.  It  is  emphasized  that 
the  contractors  will  have  access  to  appropriate  Government  data  to  use 
as  a  basis  for  initial  LSA  (baseline  operating  scenario,  support/ 
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maintenance  concept,  system  requirements  and  goals,  maintenance  and 
support  cost  data  on  current  systems,  etc).  Areas  where  the  UDB/DGTB 
is  intended  to  provide  useful  support  data  include: 

.  Identification  of  ILS  element  requirements  consistent/ 
compatible  with  system  constraints  and  goals. 

.  Identification  of  HR&LS  cost  drivers  on  current 
(similar)  systems. 

Identification  of  critical  HR&LS  parameters,  and 
analyses  to  support  establishment  of  targets,  goals, 
thresholds  for  the  system. 

.  Identification  of  requirements  for  major  support- 
related  hardware,  such  as  training  simulators, 
automated  test  equipment,  etc. 

VALIDATION  PHASE 

By  the  time  official  approval  (DSARC  1)  to  proceed  into  the  vali¬ 
dation  phase  is  obtained,  the  conceptual  design  is  essentially  comple¬ 
ted  and  a  top  level  system  specification  (functional  baseline)  is 
available.  Figure  3  shows  the  UDB/DGTB  and  user  operation  following 
DSARC  1.  The  UDB  will  contain  all  relevant  HR&LS  information  that  has 
evolved  and  expanded  throughout  the  CDP. 

UDB/DGTB  USERS 
SPO  and  Contractors 

As  the  weapon  system  progresses  through  preliminary  design,  the 
UDB  continues  to  expand  commensurate  with  lower  levels  of  system  design 
definition.  Parametric  and  design  trade-off  studies  continue,  and  the 
SPO/AFALD  and  contractors  continue  to  utilize  the  PGTB  to  support  these 
efforts . 

AFALD 

As  the  SPO/AFALD  increasingly  implements  LSA  through  contractors, 
the  expanded  LSAR  data  is  input  to  the  UDB.  Government  and  contractors 
will  utilize  the  DGTB  to  generate  estimates  of  HR&LS  requirements .  Upon 
completion  of  the  validation  phase,  the  allocated  system  baseline  is 
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essentially  defined  and  documented.  Weapon  system  documentation  will 
include  the  System  Specification,  the  Air  Vehicle  Specification  and 
Prime  Item  Development  Specifications  (Part  1).  At  this  point,  the 
UDB  will  contain  appropriate  HR&LS  related  information  at  the  subsystem 
levels.  The  DGTB  will  be  used  to  operate  on  these  data  as  desired/ 
required  to  satisfy  SPO,  AFALD,  and  otlur  user  needs  to  support  program 
management  planning  (including  LCC  estimates)  for  FSD. 

ASP 

ASD  and  AFALD  will  utilize  the  DGTB  to  operate  on  the  UDB  informa¬ 
tion  in  support  of  LCOM  studies.  The  DGTB  outputs  will  be  consistent 
and  compatible  with  LCOM. 

UDB /DGTB  INFORMATION 

During  the  validation  phase  the  UDB/DGTB  is  intended  to  provide 
information  to  support  a  DSARC  II  decision  relative  to  the  following 
areas : 

.  Conduct  trade  studies  involving  hardware,  HR&LS 

concepts  and  impacts.  Estimation  of  HR&LS  require¬ 
ments  consistent  with  system  level  performance  and 
support  parameter  goals  and  thresholds. 

.  Establishment  of  key  HR&LS  parameter  goals,  targets 
and/or  requirements  to  influence  future  design. 

Sensitivity  analyses  of  HR  and  LS  requirements  to 
changes  in  key  system  performance  parameters. 

.  Identification  of  unique,  rare  and/or  costly  skills, 

training,  and  support/ training  equipment  requirements. 

.  Establishment  of  a  contractual  baseline  operational 
scenario  and  maintenance  support  concept. 

FULL-SCALE  DEVELOPMENT  PHASE 

After  official  approval  (DSARC  II)  is  obtained  to  proceed  into 
FSD,  the  detailed  design  of  the  system  is  initiated.  It  is  noted  that 
considerable  detailed  design  of  selected  systems  may  have  been 
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accomplished  during  the  validation  phase,  particularly  if  competitive 
prototype  demonstrations  are  involved.  By  the  end  of  FSD,  the  detailed 
design,  fabrication,  assembly,  and  testing  (Category  I  and  II)  or  the 
entire  air  vehicle  system  will  have  been  accomplished.  Figure  4  shows 
the  UDB/DGTB  and  users  concept  of  operation  during  FSD.  During  this 
period,  the  SPO/AFALD  will,  primarily  through  contractors,  accomplish 
detailed  LSARs  from  which  data  are  input  to  the  UDB.  These  LSAR  data 
are  operated  upon  by  the  DGTB  to  generate  refined  HRD  to  support  final 
decisions  regarding  training  requirements ,  job  guide  (technical  data) 
development,  support  equipment,  ORLA,  etc.  The  UDB  is  used  to  provide 
outputs  to  AFLC  interfacing  systems  such  as  D-195,  D-220,  etc.  In 
addition,  the  UDB  is  used  to  support  detailed  ILS  planning,  and  to 
ensure  traceability  of  HR&LS  requirements  from  initial  goals,  targets, 
thresholds  to  the  detailed  allocated  and  specified  characteristics  in 
the  system  design,  and  to  ensure  comparability  at  detailed  levels  with 
contemporary  systems. 

PRODUCTION  PHASE  AND  OPERATIONAL  TEST  AND  EVALUATION  (OT&E) 

At  the  time  approval  for  production  is  obtained  (DSARC  III),  the 
UDB  will  contain  information  needed  to  support  ASD,  AFALD,  Air  Training 
Command  (ATC) ,  and  OP  CMD  in  the  remaining  development  and  overall 
acquisition  of  all  logistics  support  elements;  that  is,  facilities, 
support  equipment,  training  programs,  training  equipment,  manpower  job 
guides  (technical  data),  initial  and  replacement  spaces,  etc. 

AFTEC  USE  OF  UDB 

After  the  AFTEC  is  tasked  with  the  responsibility  for  OT&E  of  a 
weapon  system,  the  UDB  will  provide  consistent  and  compatible  data  for 
comparing  weapon  system  estimates  with  demonstrated  results. 

UDB  Trackabillty 

The  UDB  data  elements  will  ensure  consistency  and  compatibility 
between  RDT&E,  OT&E,  and  O&S  data  systems.  As  a  result,  the  UDB  will 
provide  a  weapon  system  history  that  will  enable  direct  comparison 
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between  initial  system  estimates  and  real-world  results  alter  deploy¬ 
ment.  This  will  be  true  for  subsystems  as  well  as  for  the  overall 
system.  The  maintenance  task  analysis  can  be  tracted  from  the  original 
LSA,  through  the  AFTEC  OT&E,  to  the  actual  field  experience  after 
deployment . 

Inactive  UDB  File 

At  some  appropriate  time  in  the  weapon  system  acquisition  process, 
primary  Air  Force  responsibility  is  shifted  from  AFSC  to  AFLC.  At  that 
time,  the  UDB  would  be  transferred  to  magnetic  tape  and  become  a  part 
of  the  Air  Force  historical  files.  Subsequently  the  O&S  records  on 
the  weapon  system  would  be  collected  and  processed  through  normal  ex¬ 
isting  data  systems  for  updating  the  historical  files.  The  DGTB  would 
retrieve,  process,  and  otherwise  operate  on  the  newly  deployed  weapon 
system  data  as  it  normally  does  to  satisfy  the  needs  of  its  users  (wea¬ 
pon  system  designers)  when  data  are  needed  from  this  historical  data 
source. 

Reactivate  for  Modifications 

The  UDB  for  the  newly  deployed  weapon  system  will  remain  in  the 
Air  Force  historical  data  file  throughout  the  life  of  the  weapon  sys¬ 
tem.  If  a  major  modification  is  required  on  an  operational  weapon 
system,  the  UDB  for  that  weapon  system  (which  is  in  the  historical 
file)  will  be  updated  as  applicable.  The  update  will  include  any  major 
changes  in  mission  as  well  as  other  relevant  data  elements.  When  the 
modification  is  completed,  the  UDB  will  be  again  transferred  to  mag¬ 
netic  tape  and  stored  in  the  historical  UDB  file. 

HISTORICAL  UDB  FILE  FOR  FUTURE  ACQUISITION  PROGRAMS 

When  ASD  is  assigned  responsibility  for  a  new  weapon  system  acqui¬ 
sition  program,  it  will  search  the  historical  UDB  file  (by  using  the 
DGTB)  to  identify  existing  weapon  systems  and  subsystems  that  are  simi¬ 
lar  to  the  new  weapon  system.  By  utilizing  the  historical  UDB,  MDCS , 
MCS ,  and  other  data  (via  the  DGTB),  the  predicted,  allocated,  and 
realized  values  for  similar  systems  can  be  investigated.  This  should 
significantly  improve  the  accuracy  of  predictive  techniques  used  earlv 


in  Che  design  process  to  influence  design  of  the  new  system.  In 
addition,  improved  accuracy  in  prediction  and  planning  for  actual  HR&LS 
requirements  should  result  in  a  smooth  transition  to  the  O&S  phase  and 
improved  cost-effectiveness  of  the  new  weapon  system. 


I 
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SECTION  V 


DEVELOPMENT  APPROACH 

GENERAL 

This  section  describes  the  recommended  approach  for  the  develop¬ 
ment  of  a  prototype  UDB/DGTB.  Since  it  is  known  that  the  Air  Force  is 
planning  a  three-phase  program  for  the  prototype  UDB,  the  discussion 
of  development  activities  presented  herein  is  tailored  to  a  three-phase 
prototype  program  as  follows: 

PHASE  I  -  UDB/DGTB  DEFINITION  AND  SYSTEM  LEVEL  DESIGN 
PHASE  II  -  UDB/DGTB  DETAILED  DESIGN  AND  DEVELOPMENT 
PHASE  III  -  UDB/DGTB  TEST,  DEMONSTRATION,  AND  TRAINING 

IMPORTANT  CONSIDERATIONS 

Assuming  that  the  concepts  of  the  UDB  and  DGTB  (Sections  III  and 
IV)  are  acceptable,  there  are  many  important  factors  to  consider  before 
the  actual  development  of  prototype  is  begun  in  Phase  II.  Moreover, 
answers  to  some  key  questions  should  be  obtained  before  the  program 
progresses  beyond  the  midpoint  of  Phase  I.  This  section  discusses  some 
alternative  development  approaches  and  raises  some  key  issues  that 
should  be  resolved  as  early  as  possible  in  Phase  I. 

INDEPENDENT  DEVELOPMENT  ALTERNATIVES 
DGTB  Development  Only 

The  DGTB  could  be  developed  and  implemented  completely  independent 
from  the  UDB.  That  is,  a  standard  DGTB  could  be  created  to  provide 
information  to  support  trade  studies/design  decisions  whether  or  not  a 
UDB  was  ever  developed.  Without  the  UDB,  however,  it  would  be  neces¬ 
sary  to  modify  the  data  inputs,  as  required,  to  achieve  compatibility 
with  the  standard  DGTB  programs.  It  would  also  be  necessary  to  modify 
the  associated  data  processing  programs  to  support  each  weapon  system 
acquisition.  In  addition,  without  a  UDB,  the  single  thread  of  HR&LS 
data  (contained  in  the  UDB  for  specific  weapon  systems)  would  not 
materialize.  This  would  mean,  of  course,  that  the  UDB  experience  data 
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would  not  be  available  to  improve  the  predictive  programs  in  the  DGTB. 

It  is  noted  that  the  utilization  of  the  single  thread  UDB  to  support 
the  design  process  for  future  weapon  systems  acquisition  is  a  major 
objective  of  the  UDB  and  is  perhaps  the  most  important  in  the  long 
term. 

UDB  Development  Only 

Conversely,  the  UDB  could  be  developed  completely  independent  of 
the  DGTB.  The  single  thread  of  HR&LS  data  could  be  developed  for  a 
specific  weapon  system  to  satisfy  the  first  two  major  objectives  of  the 
UDB.  That  is,  the  UDB  could  be  used  to  improve  planning,  avoid  dupli¬ 
cation,  and  provide  an  audit  trail  to  realistically  determine  in  OT&E 
how  well  the  weapon  system  met  its  objectives.  The  problem  is  that 
without  the  DGTB  for  use  in  the  early  design  stages,  the  UDB  informa¬ 
tion  would  be  severely  limited  and  lack  credibility  until  after  the 
detailed  LSARs  have  been  accomplished  late  in  the  full-scale  develop¬ 
ment  phase.  As  a  result,  the  UDB  would  be  developed  without  the  bene¬ 
fit  of  the  DGTB  to  influence  the  design  process. 

As  indicated  previously,  both  the  DGTB  and  the  UDB  are  needed  to 
support  the  weapon  system  acquisition  process.  The  "single  thread" 
concept  of  the  UDB  is  the  crucial  element  necessary  to  satisfy  all 
three  major  objectives  of  the  UDB.  The  DGTB  is  essential  to  ensure 
that  HR&LS  factors  are  considered  early  in  the  design  process  to  influ¬ 
ence  system  design  decisions.  The  UDB  "single  thread"  trackability  of 
data  from  conceptual  design  through  deployment  will  depend  upon  re¬ 
solving  the  incompatibilities,  providing  sources  of  data  to  fill  voids, 
elimination  of  redundancies,  and  duplication  of  effort  that  are  identi¬ 
fied  by  Thomas,  et  al.  (1979a,  1979b)  and  in  Section  II  of  this  report. 

AIR  FORCE  POLICY 

In  establishing  the  UDB  and  DGTB,  policy  guidance  and  decisions 
will  he  required  in  several  areas.  Will  the  Air  Force  support  and 
implement  procedures  (recommended  in  Report  III,  Thomas  et  al .  ,!  97l>h)  I  or 
revising  the  data  now  collected  so  as  to  achieve  compatabi 1 i tv  with 
MM. -STD-1388  task  analysis  and  AFM  bh-  )  action  taken/how  mal  I  unc  t  iotied 
codes?  These  are  far  reaching  policy  matters 
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DOD  approval,  such  as  proposed  changes  to  the  "how  malfunctioned" 
codes.  Others  are  more  easily  achieved,  such  as  the  performing  work 
center  information  in  the  LOG-MMO(AR)7142  reports,  which  are  within  the 
authority  of  the  Air  Force  to  change.  The  final  approach  to  the  devel¬ 
opment  of  the  prototype  UDB/DGTB  will  depend  on  the  answers  to  the 
questions  posed. 

There  are  other  questions  that  must  be  addressed.  In  the  case  of 
duplication/redundancy  the  possibility  exists  that  the  UDB  could  pro¬ 
vide  AFLC  data  that  could  eliminate  the  need  for  systems  such  as  D-195, 
D-220,  etc.  Policy  guidance  would  be  needed  to  determine  whether  the 
prototype  effort  should  be  accomplished  with  the  objective  of  develop¬ 
ing  a  UDB  to  eliminate  redundant  systems. 

Historically,  data  retrieval,  extraction,  processing  and  refor¬ 
matting  programs  developed  for  specific  type  data,  such  as  R&M  data 
published  in  AFALDP  800-4,  would  require  revision  based  upon  the 
Clemson  industry  survey  (Thomas  et  al.,  1979a,  1979b).  Many  recommen¬ 
dations  throughout  the  industry  requested  these  data  at  more  detailed 
levels  (3  and  4  digit  WUC) .  In  addition,  many  recommendations  were 
made  to  include  crew  size  and  elapsed  time  information  in  addition  to 
the  R&M  parameters  provided  in  AFALDP  800-4.  Furthermore,  if  the 
recommendations  made  in  the  Clemson  study  (Thomas  et  al.,  1979a,  1979b) 
for  revising  the  MIL-STD-1388  task  analysis  definitions  and  AFM  66-1 
action  taken/how  malfunctioned  codes  to  achieve  compa t ib i  1 i ty  are 
accepted,  there  is  a  need  for  a  steering  group  made  up  of  ASD/EN,  AFI.C/ 
AFALD,  AFTEC  and  selected  contractors  to  make  recommendations  for  the 
required  changes.  The  steering  group  would  provide  specific  guidance 
to  the  contractor  as  to  how  the  data  elements  are  to  he  grouped  to 
display  the  R&M  data,  such  as  that  contained  in  AFALDP  800-4,  and  to 
conform  to  the  terms  and  definitions  in  AFR  80-5. 

HISTORICAL  PERSPECTIVE 

In  the  past  years,  the  AFM  66-1  data  were  considered  to  be  primar¬ 
ily  a  base  level  reporting  system.  Ttie  majority  of  the  recommendations 
for  changes  to  the  coding  came  from  the  base  operational  level  with 
little  representation  from  AFSC/ASD.  This  was  initially  done  through 
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world-wide  maintenance  management  conferences  where  working  groups  were 
given  specific  portions  of  AFM  66-1  and  related  00-20  series  technical 
orders  to  review  and  make  recommendations  for  changes/revisions.  Since 
that  time,  the  use  of  AFM  66-1  MDCS  data  has  been  expanded  to  almost 
every  conceivable  level  of  Air  Force  maintenance  and  logistics  activity. 
However,  there  has  never,  until  the  present,  been  a  concerted  effort  on 
the  part  of  AFSC/ASD  and  AFLC  to  try  to  achieve  changes  needed  to  sup¬ 
port  future  acquisition  programs.  The  formulation  of  a  formal  steering 
group  to  ensure  that  the  UDB/DGTB  development  optimally  satisfies  these 
needs  is  crucial  to  the  ultimate  success  of  the  program. 

PHASE  I 

UDB/DGTB  DEFINITION  AND  SYSTEM  LEVEL  DESIGN 

Phase  I  of  the  prototype  UDB/DGTB  effort  will  develop  a  detailed 
definition  of  the  UDB/DGTB  to  be  developed  and  demonstrated  in  Phases 
II  and  III.  The  specific  objectives  of  Phase  I  will  be: 

(a)  Identify  and  define  the  specific  data  and  DGT  to 
be  included  in  the  prototype  development  of  the 
DGTB . 

(b)  Identify  and  define  the  specific  data  elements  to 
be  included  in  the  prototype  development  of  a  UDB. 

(c)  Identify  the  existing  data  systems  that  will  be 
utilized  by  the  UDB/DGTB  and  describe  the  inter¬ 
faces,  modifications  required,  and  operational 
modes . 

(d)  Establish  the  manner,  scope,  and  development  ap¬ 
proach  for  programming  the  DGTB  and  UDB  for  com¬ 
puter  operation. 

(e)  Establish  the  initial  procedures  for  operation  of 
UDB/DGTB,  including  accessing,  updating,  and  mainte¬ 
nance. 

INITIAL  (PARALLEL)  ACTIVITIES— STEPS  1  &  2 

The  first  step  in  the  Phase  I  development  effort  will  he  to  study 
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all  of  the  relevant  literature  to  ensure  that  the  Phase  I  effort  builds 
upon  previous  research  and  insight  obtained  from  them.  The  literature 
search  should  be  limited  to  recent  documentation  that  may  be  relevant 
to  this  effort  but  is  not  covered  in  the  Clemson  (Thomas  et  al.,  1979a, 
1979b)  and  other  key  studies.  Major  emphasis  should  be  focused  on 
critical  review/validation  of  the  suitability  of  data  systems  and  DGT 
recommended  as  the  baseline  in  this  report.  The  search  should  also 
focus  on  areas  where  existing  historical  data  and/or  technologies  are 
lacking/underdeveloped.  The  basic  purpose  of  this  portion  of  the  study 
is  to  support  objectives  (b)  and  (c)  listed  previously. 

The  second  step  (closely  related  to  parts  of  the  first)  will  be  to 
identify  and  validate  the  specific  data  needs  of  ASD/XR,  ASD/EN,  AFALD, 
AFTEC,  and  industry.  The  Clemson  industry  survey  (Thomas  et  al.,  1979a, 
1979b)  provides  information  and  insight  to  data  needed  to  support  the 
design  process.  In  addition,  the  Clemson  study  obtained  information 
regarding  the  needs  of  ASD/XR.  It  is  expected  that  the  needs  of  ASD/EN 
will  be  closely  aligned  to  the  needs  of  industry.  Rather  than  conduct 
a  survey  of  ASD/EN,  it  is  recommended  that  in  Phase  I  the  contractor  be 
required  to  first  validate  and  then  present  the  results  of  the  industry 
survey,  including  data  needs  identified,  to  key  ASD/EN  personnel  to 
identify  additional  needs.  After  accomplishment  of  or  careful  review 
of  the  AFTEC  data  system,  the  AFTEC  needs  should  be  integrated  witli 
those  of  ASD/XR,  ASD/EN,  and  industry.  A  presentation  should  then  be 
given  to  AFTEC  personnel  to  ensure  that  all  AFTEC  needs  are  identified. 
Following  that  effort  a  careful  review  of  M1L-STD-1388,  AFM  66-1,  and 
other  data  systems  should  be  conducted  to  identify  AFALD  needs.  A 
meeting  should  be  held  with  AFALD  to  ensure  that  all  data  needs  are 
identified.  It  is  recommended  that  these  meetings  with  users  be  con¬ 
ducted  separately  as  working  sessions  rather  than  combined  as  formal 
br ief ings . 

IDENTIFY/DEFINE  DATA  ELEMENTS  (STEP  3) 

Based  upon  the  results  of  steps  1  and  2,  the  third  step  will  be  to 
accomplish  objectives  (a),  (b) ,  and  (c)  listed  previously.  To  the 
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maximum  extent  practical,  all  of  the  data  needs  will  be  incorporated 
into  a  detailed  definition  of  the  UDB/DGTB  in  a  consistent,  compatible, 
and  integrated  manner.  In  addition,  the  relationships  and  interfaces 
with  existing  data  systens  will  be  identified  and  described.  The  ap¬ 
proach  to  accomplish  this  should  be  to  utilize  the  ARMY  LSAR  Automated 
Data  Processing  (ADP)  system  as  the  baseline  file  structure  and  file 
maintenance  and  up-date  procedures,  modified  as  necessary  to  satisfy 
the  Air  Force  requirements.  The  Army  programs  already  exist  with  ap¬ 
propriate  documentation  (record  layouts,  logic  flow  diagrams,  etc., 
including  user  guides). 

During  Phase  I,  the  additional  data  files  needed  to  support  an 
evolving  new  weapon  system  will  be  identified  and  defined  (i.e.,  opera¬ 
tional  scenario,  design/performance  characteristics,  support  concepts, 
etc.).  For  each  additional  data  file  established,  the  required  file 
maintenance  and  up-date  programs  will  be  described. 

DGTB  Definition 

The  outputs  of  the  DGTB  will  be  identified  so  as  to  satisfy  user 
needs,  establish  the  interface  and  compatibility  with  UDB  data  ele¬ 
ments,  accomplish  the  basic  function  of  generating  data,  and  accommo¬ 
date  user  operational  modes.  In  the  following  paragraphs,  the  desired 
data  generating  capabilities  that  would  be  most  effective  in  satisfying 
user  data  needs  in  the  conceptual  and  validation  phases  are  discussed. 
Then,  the  data  generating  technology  approach  for  the  prototype  UDB/ 
DGTB  is  discussed.  The  prototype  DGTB  approach  recognizes  the  fact 
that  not  all  of  the  desired  technologies  can  be  incorporated,  because 
of  practical  constraints  (time,  funding,  etc.). 

Desired  Data  Generating  Technology  -  Conceptual  Phase:  Bast'd  on 
ttie  Clemson  study  (Thomas  et  al.,  1979a,  1979b)  findings.  Table  1  shows 
the  generic  data  generating  capabilities  that  are  the  most  important  to 
satisfy  the  conceptual  phase  user  needs.  These  capabilities  are  listed 
in  descending  order  of  importance. 

Multiple  regression  programs  already  exist  so  establishing  that 
capability  in  the  DGTB  may  be  a  minor  task.  Establishing  the  aircraft 
characteristics,  group  weight  statements  and  TO  data  file  would  be 
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necessary,  however,  to  take  advantage  of  the  multiple  regression 
capability.  Establishing  this  file  for  inventory  systems  would  be  a 
major  task,  but  would  result  in  dramatic  improvements  in  quantity, 
quality,  and  utilization  of  HRD  to  influence  early  system  design  de¬ 
cisions.  If  this  DGTB  "multiple  regression/system  characteristics 
file"  capability  (which  would  be  compatible  with  the  UDB)  could  be  made 
available  to  all  contractors,  the  amount  of  new  HRD  generated  and  used 
to  influence  early  design  would  increase  sharply.  PERs  and  CERs  could 
be  developed  by  the  Government  and  contractors  for  R,  M  (including 
skills,  skill  levels,  crew  size,  etc.),  ground  support  and  test  equip¬ 
ment,  training  programs  and  equipment,  job  guides  (technical  data),  and 
ground  support  manpower  costs.  These  estimates  could  be  developed  at 
the  top  system  level  and  subsystem  levels  for  use  throughout  the  con¬ 
ceptual  phase.  There  is  also  a  need  for  a  standard  data  normalization 
program.  This  ancillary  program  would  be  incorporated  into  the  DGTB, 
and  the  input  data  for  the  regression  program  would  be  first  operated 
upon  by  this  program.  Utilization  adjustment  is  a  good  example  of 
normalizing  needs. 

TABLE  1.  DESIRED  CONCEPTUAL  PHASE  DOT 

.  Multiple  Regression  Programs. 

.  Existing  PER/CER  (Equations  and  Parameter 
description  files). 

.  Aircraft  Characteristics,  Weight  Statements 
and  TO  Data  File  (AFG-2  &  AN9103-D). 

Data  Normalizing  Programs  (utilization  falls 
in  this  category). 

.  A()  Assessment  Program 

.  Life  Cycle  Cost  Model/Program 

Utilization  adjustment  programs  and  availability  assessment  tech¬ 
nology  has  been  developed  (programs  will  be  modified)  and  would  be  the 
next  most  important  and  useful  technology  for  use  in  the  conceptual 
phase.  These  DGTB  capabilities  would  provide  the  mechanism  to  generate 
and  utilize  HRM.S  impact  estimates  in  a  manner  which  is  compatible  with 
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and  supportive  of  the  system  design  process.  The  LCC  model  capability 
in  the  UDB/DGTB  would  then  be  able  to  utilize  the  outputs  of  the  above 
data  generating  capabilities,  and  should  result  in  greatly  improved  LCC 
estimates  to  support  program  management  and  DSARC  I  decisions. 

Desired  DOT  -  Validation  Phase:  Table  4  shows  the  additional 
generic  data  generating  capabilities  that  are  most  important  to  satisfy 
the  validation  phase  user  needs.  All  of  the  DCTB  capabilities  needed 

TABLE  4.  DESIRED  VALIDATION  PHASE  DOT 

.  Logistics  Composite  Model  (LOOM)  Programs 
EX  -  VAL 

Common  Data  Extraction  Programs  (CDEP) 

URIA  Programs 
.  Army  LSAR  Programs 

.  Inspection  Requirements  Assessment  Programs 
.  Other  Human  Resources  Technologies 


for  the  conceptual  phase  will  continue  to  be  needed  and  used  in  the 
validation  phase. 

The  LC’OM,  EX- VAL ,  and  CDEP  programs  may  be  very  useful  in  the 
later  stages  of  the  conceptual  phase  and  will  be  of  great  value  in  the 
validation  phase.  ORLA  programs  will  be  useful  throughout  this  phase 
to  support  the  design  process  and  UDB  development.  The  Army  LSAR  pro¬ 
grams  will  be  useful  early  in  the  validation  phase,  and  may  be  useful 
during  the  conceptual  phase.  It  may  be  necessary  to  accomplish  major 
modifications  to  the  Army  programs  in  order  to  ;atisfv  Air  Force  re¬ 
quirements.  An  inspection  requ  i  rements  assessn ent  progr;im  would  be 
useful,  but  a  data  base  of  required  information  does  not  exist.  Modi¬ 
fication  to  AFTO  349,  recommended  in  Report  III  (Thomas  et  al.,  1979a, 
1979b),  would  be  required  to  establish  the  data  base.  If  the  data 
base  were  created,  the  DCTB  program  to  generate  useful  and  usable  HRD 
could  be  developed  and  implemented.  The  technology  developed  by  AFHRL 
(Goclowski,  1978a,  1978b,  1978c)  may  hi'  useful  in  this  phase  >f  an 
acquisition  program. 
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Prototype  DCT  -  The  above  discussion  of  desired  DGT  was  based  on 
an  objective  assessment  of  the  actual  needs  and  technologies/capabili¬ 
ties  required  to  best  satisfy  those  needs.  The  time  and  funding  con¬ 
straints  of  a  prototype  UDB/DGTB  development  program  would  not  permit 
the  desired  DGTB  capabilities  to  be  fully  incorporated.  The  prototype 
UDB/DGTB  should,  however,  incorporate  as  many  capabilities  as  possible 
Table  5  shows  the  technologies/capabilities  that  should  be  considered 
for  incorporation  into  the  prototype  UDB/DGTB  in  their  order  of  impor¬ 
tance  recognizing  time,  funding  and  procedural  constraints.  (See 
Figure  2  for  a  more  detailed  discussion  of  candidate  technologies.) 

TABLE  5.  PROTOTYPE  DGT 


.  Army  LSAR  Programs 

.  LOOM  Programs  (F.X-VAL  &  CDEP) 

.  CER/PER  (Existing)  Models  and  Programs 

.  ORLA  Program 

.  Assessment  Program 

.  Multiple  Regression  Program 

.  Aircraft  Characteristics  &  TO  Group  Weight 
Statements  Files  (AFC-2  &  AN9103-D) 

.  Inspection  Requirements  Assessment  Program 


Summary  of  UDB/DGTB  Def inition 

The  UDB/DGTB  system  definition  should  specifically  define  programs, 
data  elements,  functions,  interfaces,  and  operation  of  the  system.  UDB/ 
DGTB  system  definition  should  include  all  data  files  and  data  genera¬ 
ting  technologies  to  be  incorporated  and  modifications  required.  In 
addition,  the  extent  of  programming  and  compatibility  modifications 
required  to  retrieve  and  process  historical  data  from  existing  systems 
so  as  to  be  consistent  with  the  UDB  should  be  defined.  Finally,  it 
should  include  the  UDB  data  elements  and  LSAR  data  processing  programs, 
including  modification  and  programming  requirements. 

Prog res s  R eview  and  Go-Ahead 

At  this  point  in  the  Phase  I  program,  it  is  recommended  tiiat  the 


Air  Force  convene  a  steering  group  meeting  to  receive  a  contractor 
presentation  on  the  integrated  data  needs  of  all  users-  This  meeting 
should  occur  not  later  than  halfway  through  the  Phase  I  time  period. 

It  is  envisioned  that  at  this  time  the  Phase  I  contractor  will  have 
essentially  completed  objectives  (a),  (b) ,  and  (c)  of  Phase  I.  In 
addition,  the  contractor  should  receive  Air  Force  guidance  regarding 
any  unresolved  policy  issues  and  the  acceptability  of  proceeding  with 
the  remaining  objectives  of  Phase  I  based  upon  the  defined  UDB/DGTB  and 
interfacing  systems. 

PERFORM  INITIAL  SYSTEM  DESIGN 

The  fourth  step  will  be  to  establish  the  initial  design  of  the 
prototype  UDB/DGTB  system  and  the  detailed  development  plan  for  Phase 
II.  This  effort  will  establish  the  manner,  scope,  and  development  ap¬ 
proach  for  programming  the  DGTB  and  UDB  for  computer  operation  (Phase  1 , 
Objective  (d)).  The  initial  system  design  will  involve  development  of 
the  criteria  for  the  retrieval,  file  maintenance,  and  update  programs 
(load,  add,  change,  delete,  and  save)  for  the  UDB  and  approximately  six 
of  the  DGTs  listed  in  "DGTB  definition."  The  specific  DGTs  to  be  in¬ 
corporated  will  be  agreed  upon  in  the  Air  Force  review  (previous  para¬ 
graph).  The  specific  data  elements  and  outputs  of  each  DGT  will  re¬ 
quire  thorough  analysis  for  compatibility  with  the  data  elements  of  the 
UDB  (compatible  with  MIL-STD-1388) .  This  effort  will  establish  the 
manner,  scope  and  development  approach  for  programming  the  UDB  and  DGTB 
for  computer  operation. 

ESTABLISH  CONCEPT  OF  OPERATION 

The  fifth  and  final  step  in  Phase  I  will  be  to  accomplish  objec¬ 
tive  (e).  This  effort  will  provide  the  concept  and  proposed  procedures 
for  operation  of  the  UDB/DGTB  including  accessing,  updating,  and  main¬ 
tenance.  Special  emphasis  will  be  focused  upon  proposed  procedures 
to  be  developed  and  demonstrated  in  Phases  II  and  III  of  the  prototype 
program. 
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PHASE  II 


UDB/DCTB  DEVELOPMENT 

The  actual  development  of  the  prototype  UDB/DCTB  will  be  accom¬ 
plished  in  Phase  II.  System  specifications  will  he  developed  to  the 
level  of  detail  necessary  for  programming  to  he  accomplished.  Pro¬ 
gramming  will  then  be  accomplished  and  program  documentation  developed 
(record  formats,  data  element  definition,  etc.)  as  required  to  ade¬ 
quately  document  the  programs.  Users  manuals/procedures  will  then  he 
developed . 

UDB  PROGRAMMING  SPECIFICATION 

A  detailed  specification  for  the  UDB  will  he  prepared.  This  docu¬ 
ment  will  identify  the  data  elements  that  the  UDB  will  contain,  space 
requirements  for  each,  and  the  format  of  the  elements  in  the  data  base. 
Specific  space  for  growth  of  the  base  will  be  provided.  The  specifica¬ 
tion  will  delineate  the  location  and  format  of  the  various  sources  of 
each  data  element.  Any  multiple  spaces  that  are  to  he  provided  for  the 
same  parameters  will  be  identified.  The  specification  will  del  incat  ■ 
the  required  update  capabilities.  Specific  options,  methods,  tech¬ 
niques  for  display  of  the  data  will  be  specified.  Subroutines,  desired 
for  basic  manipulation  of  the  data  will  be  specified.  These  routines 
include  options  such  as  sort  and  display  certain  parameters  by  sort 
sequence  or  part  number  sequence;  simple  rate  X  quantity  summations  for 
selected  subsystems  or  parts,  and  selective  displays  three  or  four 
digit  codes;  from- to  sequences  of  codes  or  part  number,  etc.  These 
capabilities  of  the  UDB  are  not  to  be  confused  with  the  more  sophisti¬ 
cated  programs  associated  with  the  DGTB.  Provisions  for  the  capture 
and  permanent  retention  of  data  elements  prior  to  each  update  will  In' 
specified.  This  is  necessary  to  provide  a  complete  audit  trail  as  the 
weapon  systems  progress  through  the  various  development  stages.  This 
type  of  historical  data  retention  is  vital  to  the  overall  success  oi 
and  effective  utilization  of  the  UDB/DGTB  technology.  This  specifica¬ 
tion  will  also  include  the  extent  of  program  tlexibilitv  required  to  be 
compatible  with  the  CDG  6600  computer  system  at  ASD,  as  well  as  the 


IBM  370  and  Larger  IBM  computer  systems.  The  programming  language  used 
will  he  coordinated  and  approved  by  the  Air  Force. 

DGTB  PROGRAMMING  SPECIFICATION 

The  DGTB  is  conceived  of  as  an  expandable  series  of  computer  pro¬ 
grams  that  perform  HR  analyses  and/or  provide  data  related  thereto.  As 
such,  it  shall  be  comprised  of  a  number  of  separate  computer  programs, 
and/or  data  products,  most  of  which  already  exist  in  various  forms.  The 
DGTB  specification  will  therefore  primarily  address  the  revisions  and 
modifications  required  to  unify  these  models/ technologies  so  as  to  be 
compatible  with  the  computer  system,  data  sources,  UDB  data  elements, 
etc.  Ttie  specification  will  delineate  input  sources  and  formats  for 
each  technology,  many  of  which  will  come  from  the  UDB,  and  will  specify 
and  describe  to  what  extent  the  outputs  of  each  of  these  technologies 
will  be  stored  in  the  UDB.  The  extraction  of  input  data  from  the  UDB 
and  input  of  selected  results  to  the  UDB  by  those  technologies  will  be 
specified.  Interactive  communication  will  be  specified.  Programs 
between  the  UDB  and  the  DGTB  for  data  transfer  will  be  included  in  this 
specif icat ion. 

The  DGTB  specification  will  include  a  provision  for  a  protected 
storage  location  within  the  computer  where  data  and/or  programs  may  be 
sorted  and  retrieved  for  analysis  purposes.  This  storage  location  will 
also  provide  for  limited  expansion  of  the  DGTB  to  fit  the  unique  or 
special  needs  of  an  individual  user.  The  DGTB  system  definition  would 
allow  for  future  expansion  in  order  to  add/modifv  technologies . 

PROGRAMMING 

The  detailed  specification  of  the  UDB  and  that  of  the  DGTB  will 
commence  on  a  concurrent  basis.  Programming  associated  therewith  will 
commence  as  various  segment  specifications  are  finalized.  Programs 
will  be  written  in  Fortran  (or  some  other  suitable  language)  and  will 
be  first  established  to  operate  on  the  contractor’s  computer.  The 
ability  to  convert  these  programs  to  the  CDC  bbOO  and  IBM  370  systems 
will  be  a  firm  constraint.  Difierences  in  tape  densities,  memory 


sizes,  dimensions,  statements,  etc.  will  be  specially  delineated  in  the 
program  documentation. 

USERS  HANDBOOK 

The  contractor  will  provide  a  users  handbook  that  contains  specif¬ 
ic  instructions  for  operating  both  the  UDB  and  the  DGTB.  This  handbook 
will  completely  delineate  all  capabilities  of  both  bases  and  specifi¬ 
cally  how  each  capability  can  be  accessed  and  utilized  via  remote  con¬ 
soles  and/or  batch  output  directly  from  the  computer  center.  Step-by- 
step  keyboard  strokes  will  be  included  for  use  of  each  program.  Exam¬ 
ple  inputs  and  resulting  outputs  will  be  included.  Limitations  of  both 
data  and  technology  bases  will  be  clearly  stated.  Simplified  instruc¬ 
tions  for  non-programmers  pertaining  to  iiow  to  call  up  programs,  how  to 
call  up  data,  how  to  execute  programs,  etc.  will  be  clearly  provided  in 
the  users  handbook. 

PROGRAM  DOCUMENTATION 

Detailed  documentation  of  each  UDB  and  DGTB  program  will  be  devel¬ 
oped.  This  will  include  record  formats,  detailed  data  element  identi¬ 
fication  and  description,  computer  codes,  and  data  file  descriptions. 

PHASE  III 

TEST  AND  DEMONSTRATION 

The  prototype  UDB/DGTB  will  be  developed  so  as  to  be  compatible 
with  other  computer  systems  currently  in  use.  Specifically,  the  system 
will  be  compatible  with  the  CDC  6600  and  IBM  370  equipment.  Remote 
terminals  will  be  established  at  Wright-Pat terson  AFB  and  at  least  one 
contractor  facility.  After  the  prototype  UDB/DGTB  is  developed  and  all 
programs  are  operating,  the  system  will  be  demonstrated  using  actual  or 
representative  data  to  load  an  initial  UDB  for  a  weapon  system  that  is 
in  the  conceptual  phase.  Users  will  access  the  central  data  processor 
of  the  system  and  exercise  I.SAR  and  DGTB  programs  to  generate  data  as 
is  applicable  and  appropriate.  It  is  recommended  that,  if  possible, 

the  same  exercise  be  accompl  i  sited  for  a  weapon  system  that  is  in  the 

-63- 


r 


validation  phase.  It  may  be  feasible  and  practical  to  use  a  recently 
developed  system  (  K-  1  5 ,  K-16,  etc.)  to  simulate  an  evolving  weapon  sys¬ 
tem  program  to  demonstrate  the  UDB/DCTB.  That  way,  multiple  program 
phases  could  be  "experimentally  conducted"  to  test  the  utility  and 
validity  of  the  UDB/DGTB,  with  the  advantage  of  having  actual  data  for 
comparison.  The  difficulties  of  designing  a  realistic  and  objective 
experiment  would  be  proportional  to  the  degree  to  which  the  early  pro¬ 
gram  activities  (trades,  specifications,  etc.)  were  documented  and  to 
the  availability  of  such  data. 
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